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INTRODUCTION 

VMEbus is the most popular 16/32-bit backplane bus. Its use of the Eurocard format, 
its high performance, and its versatility are some of the reasons that it appeals to a 
wide range of users. The designer friendly and user friendly style of its specification 
offers useful advice and helps ensure compatibility between VMEbus products. 

The following VMEbus specification is a result of both IEEE P1014 Standard 
Committee and the lEC 47b Standards Committee work. The version of the VMEbus 
specification presented here (Revision C.1) has been approved by the IEEE P1014 
Standard Committee as draft 1.2. It is presently undergoing the final stages of 
approval in both the IEEE and the lEC. While the final IEEE 1014 and lEC 821 BUS 
standards are not expected to differ significantly from Revision C.I, the publisher of 
this document does not guarantee that those standards will not differ at all. This 
document is being published to provide the VMEbus community with an up-to-date 
professional and readable document in the hope of promoting compatibility between 
VMEbus products and encouraging the widespread use of VMEbus. 



DISCLAIMER 

The IEEE, the lEC, VITA, the companies, and all individuals who contributed to the 
development of this document make no warranty for the use of the VMEbus, nor for 
products interfacing to the VMEbus, and they assume no responsibility for errors 
appearing in this document. 
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THE HISTORY OF THE VMEbus 

The architectural concepts of VMEbus date back to Motorola's development of the 
second generation 68000 microprocessor in the late 1970's. A team of engineers at 
Motorola Microsystems (Phoenix, Arizona) led by Jack Kister, designed a 68000 
development system called the EXORmacs. The backplane of the EXORmacs was 
called VERSAbus. While coordinating the efforts of his team, Jack wrote a brief 41 
page bus description of VERSABus which was published in November of 1979. The 
first EXORmacs was shipped in January 1 980. 

Shortly after that, John Black was assigned the job of developing a new line of board 
products called VERSAmodules. Upon review of the existing documentalion, he 
concluded that it was insufficient to guarantee compatibility between independently 
designed boards. As a result, he and Jack Kister began refining the documentation. 

As VERSAmodule boards were designed, inadequacies in the existing documentation 
were uncovered and corrected. In December of 1980, Motorola published a much 
expanded 188 page version of the VERSAbus specification. One month later that 
company shipped its first VERSAbus-based single board computer, called the 
VERSAmodule 1. During the next six months, as John continued refining the 
specification. Motorola published 3 more revisions and in July of 1981 it published the 
fifth and last revision, which consisted of 240 pages. 

During this same time Motorola's European Microsystems group in Munich, Germany 
proposed the development of a VERSAbus-like product line based on the Eurocard 
board size. To demonstrate the concept. Max Loesel and Sven Rau developed three 
prototype boards: a 68000 CPU board, a dynamic RAM board, and a static RAM board. 
They named the bus VERSAbus-E. 

Shortly after this, Motorola licensed both Mostek (Carrolton, Texas) and N.V. 
Philips/Signetics (Sunnyvale, California) to second source the 68000 and co-develop 
support chips for the 68000 family. Since both of these companies planned to 
manufacture board products, Motorola invited them to discuss the possibility of jointly 
supporting a bus. As a result of that meeting, all three companies agreed to support 
VERSAbus-E, which they renamed VMEbus. 

John Black of Motorola, Craig Mackenna of Mostek, and Cecil Kaplinsky of Signetics, 
acting as technical representatives for their respective companies, took the fifth 
revision of the VERSAbus specification and developed the first VMEbus specification, 
Revision A. In October 1981, the three companies announced their joint support of 
VMEbus at the "Systems 81" show in Munich, Germany. Just before the joint press 
conference Thompson CSF (France) also agreed to announce its support of VMEbus. 

In August of 1982 the VMEbus manufacturer's group published a second version of 
the specification, called Revision B. Revision B refined the specifications for the signal 
line drivers and also brought the mechanical specifications more into line with the 
developing lEC 297-3 Eurocard standard. 



During 1982 the French delegation to the International Electrotechnical Commission 
(lEC) proposed VMEbus as an International standard. The lEC established a 
subcommittee under its 47b committee to start formal standardization of VMEbus, 
calling it the lEC 821 BUS. Mira Pauker of Philips was given editorial responsibility. 

In March of 1983 the IEEE Microprocessor Standards Committee voted to establish a 
committee of their own to standardize VMEbus, which the IEEE later gave the name 
IEEE PI 01 4. Wayne Fischer was appointed chairman. John Black agreed to serve as 
chairman of the PI 01 4 technical subcommittee. 

Both the lEC and IEEE distributed copies of Revision B for comment, and both 
received requests for changes. John Black and Shiomo Pri-Tal (of Motorola) 
incorporated changes from both sources into a common document. The resulting 
document, called Revision C, was published by Motorola in February of 1985 and 
distributed by VITA. 

While Revision C was being circulated, the IEEE PI 01 4 Standard Committee balloted 
it members for approval of that document, which they called "Draft 1.0". 51 of the 86 
members approved the document. (17 of those who sent in approvals also included 
editorial changes that they felt would be beneficial.) Ten members disapproved 
unless certain changes were made. Six members abstained, and 19 members failed 
to return the ballot. The committee met in April of 1985 to consider these changes and, 
at the conclusion of that meeting, the 24 attending members voted unanimously to 
support the document as amended. These amendments were then forwarded to the 
lEC committee. John Black and Shiomo Pri-Tal incorporated these changes into the 
Revision C data base and called it Revision C.I (The IEEE P1014 Standard 
Committee approved this document under the name "Draft 1 .2".) 
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PREFACE 

by the Executive Director of VITA, Lyman Hevle. 

The VMEbus International Trade Association (VITA) was formed in November, 1984, 
to accelerate the technical and commercial success of the VMEsystem architecture. At 
that time VITA assumed the functions of the then existing VMEbus manufacturer's 
group and the VMEbus user's group. 

VITA'S Technical Committee provides a forum for discussion and review of VMEbus 
related specifications. Members of the Technical Committee have contributed heavily 
to both the IEEE's and the lEC's standardization of Revision C.1. 

This Revision C.1 specification has been reviewed and approved by the VITA 
Technical Committee which recognizes it as the official reference for VMEbus designs. 
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CHAPTER 1 
INTRODUCTION TO THE VMEbus SPECIFICATION 

1.1 VMEbus SPECIFICATION OBJECTIVES 

The VMEbus specification defines an interfacing system used to interconnect data 
processing, data storage, and peripheral control devices in a closely coupled 
hardware configuration. The system has been conceived with the following objectives: 

a. To allow communication between devices on the VMEbus without disturbing the 

internal activities of other devices interfaced to the VMEbus. 

b. To specify the electrical and mechanical system characteristics required to design 
devices that will reliably and unambiguously communicate with other devices 
interfaced to the VMEbus. 

c. To specify protocols that precisely define the interaction between the VMEbus and 

devices interfaced to it. 

d. To provide terminology and definitions that describe system protocols. 

e. To allow a broad range of design latitude so that the designer can optimize cost 
and/or performance without affecting system compatibility. 

f. To provide a systehri where performance is primarily device limited, rather than 

system interface limited. 

(■ 

1.2 VMEbus INTERFACE SYSTEM ELEMENTS 
1.2.1 Basic Definitions 

The VMEbus structure can be described from two points of view: its mechanical 
structure and its functional structure. The mechanical specification describes the 
physical dimensions of subracks, backplanes, front panels, plug-in boards, etc. The 
VMEbus functional specification describes how the bus works, what functional 
modules are involved in each transaction, and the rules which govern their behavior. 
This section provides informal definitions for some basic terms used to describe both 
the mechanical and the functional structure of the VMEbus. 

1.2.1.1 Terms Used To Describe The VMEbus Mechanical Structure 

VMEbus BACKPLANE -- A printed circuit (PC) board with 96 pin connectors and 
signal paths that bus the connector pins. Some VMEbus systems have a smgle PC 
board, called the J1 backplane. It provides the signal paths needed for basic 
operation. Other VMEbus systems also have an optional second PC board, called a 
J2 backplane. It provides the additional 96 pin connectors and signal paths needed 
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for wider data and address transfers. Still others have a single PC board that provides 
the signal conductors and connectors of both the J1 and J2 backplanes. 

BOARD - A printed circuit (PC) board, its collection of electronic components, and 
either one or two 96 pin connectors that can be plugged into VMEbus backplane 
connectors. 

SLOT -- A position where a board can be inserted into a VMEbus backplane If the 
VMEbus system has both a J1 and a J2 backplane (or a combination J1/J2 backplane) 
each slot provides a pair of 96 pin connectors. If the system has only a J1 backplane 
then each slot provides a single 96 pin connector. 

SUBRACK - A rigid framework that provides mechanical support for boards inserted 
into the backplane, ensuring that the connectors mate properly and that adjacent 
boards do not contact each other. It also guides the cooling airflow through the 
system, and ensures that inserted boards do not disengage themselves from the 
backplane due to vibration or shock. 

1.2.1.2 Terms Used To Describe The VMEbus Functional Structure 

Figure M shows a simplified block diagram of the functional structure, including the 
VMEbus signal lines, backplane interface logic, and functional modules. 

BACKPLANE INTERFACE LOGIC - Special interface logic that takes into account 
the characteristics of the backplane: its signal line impedance, propagation time, 
ternriination values, etc. The VMEbus specification prescribes certain rules for the 
design of this logic based on the maximum length of the backplane and its maximum 
number of board slots. 

FUNCTIONAL MODULE -- A collection of electronic circuitry that resides on one 
VMEbus board and works together to accomplish a task. 

DATA TRANSFER BUS - One of the four buses provided by the VMEbus 
backplane. The Data Transfer Bus allows MASTERS to direct the transfer of binary 
data between themselves and SLAVES. (Data Transfer Bus is often abbreviated 
DTB.) 

DATA TRANSFER BUS CYCLE -- A sequence of level transitions on the signal 
lines of the DTB that result in the transfer of an address or an address and data 
between a MASTER and a SLAVE. The Data Transfer Bus cycle is divided into two 
portions, the address broadcast, and then zero or more data transfers. There are 34 
types of Data Transfer Bus cycles. They are defined later in this chapter. 

MASTER - A functional module that initiates DTB cycles in order to transfer data 
between itself and a SLAVE module. 
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B SLAVE "A functional module that detects DIB cycles initiated by a MASTER and 
y^-']!"^^^^® ^y^'®^ specify its participation, transfers data between itself and the 
MASTER. 

LOCATION MONITOR - A functional module that monitors data transfers over the 
DTB in order to detect accesses to the locations it has been assigned to watch. When 
an access to one of these assigned locations occurs, the LOCATION MONITOR 
generates an on-board signal. 

BUS TIMER - A functional module that measures how long each data transfer takes 
on the DTB and terminates the DTB cycle if a transfer takes too long. Without this 
module, if the MASTER tries to transfer data to or from a non-existent SLAVE location it 
might wait forever. The BUS TIMER prevents this by terminating the cycle. 

PRIORITY INTERRUPT BUS -- One of the four buses provided by the VMEbus 
backplane. The Priority Interrupt Bus allows INTERRUPTER modules to send interruDt 
requests to INTERRUPT HANDLERS. 

INTERRUPTER - A functional module that generates an interrupt request on the 
Pnority Interrupt Bus and then provides STATUS/ID information when the INTERRUPT 
HANDLER requests it. 

INTERRUPT HANDLER -- A functional module that detects interrupt requests 
generated by INTERRUPTERS and responds to those requests by askinq for 
STATUS/ID information. ^ 

DAISY-CHAIN -A special type of VMEbus signal line that is used to propagate a 
signal level from board to board, starting with the first slot and ending with the last slot. 
There are four bus grant daisy-chains and one interrupt acknowledge daisy-chain on 
the VMEbus. 

lACK DAISY-CHAIN DRIVER - A functional module which activates the interrupt 
acknowledge daisy-chain whenever an INTERRUPT HANDLER acknowledges an 
interrupt request. This daisy-chain ensures that only one INTERRUPTER will respond 
with its STATUS/ID when more than one has generated an interrupt request. 

ARBITRATION BUS - One of the four buses provided by the VMEbus backplane. 
This bus allows an ARBITER module and several REQUESTER modules to coordinate 
use of the DTB. 

REQUESTER - A functional module that resides on the same board as a MASTER 
or INTERRUPT HANDLER and requests use of the DTB whenever its MASTER or 
INTERRUPT HANDLER needs it. 

ARBITER - A functional module that accepts bus requests from REQUESTER 
modules and grants control of the DTB to one REQUESTER at a time. 



INTRODUCTION 

UTILITY BUS - One of the four buses provided by the VMEbus backplane. This bus 
includes signals that provide periodic timing and coordinate the power-up and power- 
down of VMEbus systems. 

SYSTEM CLOCK DRIVER -A functional module that provides a 16 MHz timing 
signal on the Utility Bus. 

SERIAL CLOCK DRIVER - A functional module that provides a periodic timing 
signal that synchronizes operation of the VMSbus. (Although the VMEbus 
specification defines a SERIAL CLOCK DRIVER for use with the VMSbus, and 
although it reserves two backplane signal lines for use by that bus, the VMSbus 
protocol is completely independent of the VMEbus). Timing specifications for the 
SERIAL CLOCK DRIVER are given in Appendix C. 

POWER MONITOR MODULE ~ A functional module that monitors the status of the 
primary power source to the VMEbus system, and signals when that power has 
strayed outside the limits required for reliable system operation. Since most systems 
are powered by an AC source, the POWER MONITOR is typically designed to detect 
drop-out or brown-out conditions on AC lines. 

SYSTEM CONTROLLER BOARD - A board which resides in slot 1 of a VMEbus 
backplane and has a SYSTEM CLOCK DRIVER, an ARBITER, an lACK DAISY-CHAIN 
DRIVER, and a BUS TIMER. Some also have a SERIAL CLOCK DRIVER, a POWER 
MONITOR or both. 

1.2.1-3 Types Of Cycles On The VMEbus. 

READ CYCLE - A DTB cycle used to transfer 1 , 2, 3, or 4 bytes from a SLAVE to a 
MASTER. The cycle begins when the MASTER broadcasts an address and an 
address modifier. Each SLAVE captures the address modifier and address, and 
checks to see if it is to respond to the cycle. If so, it retrieves the data from its internal 
storage, places it on the data bus and acknowledges the transfer. The MASTER then 
terminates the cycle. 

WRITE CYCLE ~ A DTB cycle used to transfer 1 , 2, 3, or 4 bytes from a MASTER to a 
SLAVE. The cycle begins when the MASTER broadcasts an address and address 
modifier and places data on the DTB. Each SLAVE captures the address and address 
modifier and checks to see if it is to respond to the cycle. If so, it stores the data and 
then acknowledges the transfer. The MASTER then terminates the cycle. 

BLOCK READ CYCLE - A DTB cycle used to transfer a block of 1 to 256 bytes from 
a SLAVE to a MASTER. This transfer is done using a string of 1, 2, or 4-byte data 
transfers. Once the block transfer is started, the MASTER does not release the DTB 
until all of the bytes have been transferred. It differs from a string of read cycles in that 
the MASTER broadcasts only one address and address modifier (at the beginning of 
the cycle). Then the SLAVE increments this address on each transfer so that the data 
for the next transfer is retrieved from the next higher location. 
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BLOCK WRITE CYCLE - A DIB cycle used to transfer a block of 1 to 256 bytes 
from a MASTER to a SLAVE. The block write cycle is very similar to the block read 
cycle. It uses a string of 1, 2, or 4-byte data transfers and the MASTER does not 
release the DTB until all of the bytes have been transferred. It differs from a string of 
wnte cycles in that the MASTER broadcasts only one address and address modifier (at 
the beginning of the cycle). Then the LAVE increments this address on each transfer 
so that the data from the next transfer is stored in the next higher location. 

READ-MODIFY-WRITE CYCLE - A DTB cycle that is used to both read from, and 
write to a SLAVE location without permitting any other MASTER to access that 
ocation. This cycle is most useful in multiprocessing systems where certain memory 
locations are used to provide semaphore functions. 

ADDRESS-ONLY CYCLE - A DTB cycle that consists of an address broadcast, but 
"° °?1? transfer. SLAVES do not acknowledge ADDRESS-ONLY cycles and 
MASTERS terminate the cycle without waiting for an acknowledgment. 

L^lf^.lHf "^ ACKNOWLEDGE CYCLE - A DTB cycle, initiated by an INTERRUPT 
HANDLER, that reads a STATUS/ID from an INTERRUPTER. An INTERRUPT 
^;i'!iBt^f^ generates this cycle whenever it detects an interrupt request from an 
INTERRUPTER and it has control of the DTB. 

1.2.2 Basic VMEbus Structure 

The VMEbus interface system consists of backplane interface logic, four groups of 
signal lines called "buses", and a collection of "functional modules" which can be 
configured as required. The functional modules communicate with each other usina 
the backplane signal lines. 

The "functional modules" defined in this document are used as vehicles for discussion 
of the bus protocol, and need not be considered a constraint to logic design. For 
example, the designer might choose to design logic which interacts with the VMEbus 
w»J^? manner described, but uses different on-board signals, or monitors other 
VMEbus signals. VMEbus boards might be designed to include any combination of 
the functional modules defined by this document. 

The VMEbus functional structure can be divided into four categories. Each consists of 
a bus and its associated functional modules which work together to perform specific 
duties. Figure 1-2 shows the VMEbus functional modules and buses. Each cateaorv 
is briefly summarized below. 

Data Transfer - Devices transfer data over the Data Transfer Bus (DTB), which 
contains data and address pathways and associated control signals. Functional 
modules called MASTERS. SLAVES, INTERRUPTERS, and INTERRUPT HANDLERS 
use the DTB to transfer data between each other. Two other modules, called a BUS 
TIMER and an JACK DAISY-CHAIN DRIVER also assist them in this process. 
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DTB Arbitration - Since a VMEbus system can be configured with more than one 
MASTER or INTERRUPT HANDLER, a means is provided to transfer control of the DTB 
between them in an orderly manner and to guarantee that only one controls the DTB at 
a given time. The Arbitration Bus modules (REQUESTERS and ARBITER) coordinate 
the control transfer. 

Priority Interrupt - The priority interrupt capability of the VMEbus provides a means 
by which devices can request service from an INTERRUPT HANDLER. These interrupt 
requests can be prioritized into a maximum of seven levels. INTERRUPTERS and 
INTERRUPT HANDLERS use the Priority Interrupt Bus signal lines. 

Utilities - Periodic clocks, initialization, and failure detection are provided by the 
Utility Bus. It includes two clock lines, a system reset line, a system fail line, an AC fail 
line, and a serial data line. 

1.3 VMEbus SPECIFICATIONS DIAGRAMS 

As aids to defining or describing VMEbus operation, several types of diagrams are 
used, including: 

a. Timing diagrams that show the timing relationships between signal transitions. The 
times involved will have minimum and/or maximum limits associated with them. 
Some of the times specified on these diagrams specify the behavior of the 
backplane interface logic, while other times specify the interlocked behavior of the 
functional modules. 

b. Sequence diagrams that are similar to a timing diagram but show only the 
interlocked timing relationships of the functional modules. This diagram is 
intended to show a sequence of events, rather than to specify the times involved. 
For example, a sequence diagram might indicate that module A cannot generate 
signal transition B until it detects module C's generation of signal transition D. 

c. Flow diagrams that show a stream of events as they would occur during a VMEbus 
operation. The events are stated in words and result from interaction of two or 
more functional modules. The flow diagram describes VMEbus operations in a 
sequential manner and, at the same time, shows interaction of the functional 
modules. 
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1.4 SPECIFICATION TERMINOLOGY 



To avoid confusion, and to make very clear what the requirements for compliance are, 
many of the paragraphs in this document are labeled with keywords that indicate the 
type of information they contain. The keywords are listed below: 

RULE 

RECOMMENDATION 

SUGGESTION 

PERMISSION 

OBSERVATION 

Any text not labeled with one of these keywords describes the VMEbus structure or 
operation. It is written in either a descriptive or a narrative style. These keywords are 
used as follows: 

RULE chapter.number: 

Rules form the basic framework of the VMEbus specification. They are sometimes 
expressed in text form and sometimes in the form of figures, tables, or drawings. All 
VMEbus rules MUST be followed to ensure compatibility between VMEbus designs. 
Rules are characterized by an imperative style. The upper-case words MUST and 
MUST NOT are reserved exclusively for stating rules in this document and are not 
used for any other purpose. 

RECOMMENDATION chapter.number: 

Wherever a recommendation appears, designers would be wise to take the advice 
given. Doing otherwise might result in some awkward problems or poor performance. 
While VMEbus has been designed to support high performance systems, it is possible 
to design a VMEbus system that complies with all the rules, but has abysmal 
performance. In many cases, a designer needs a certain level of experience with 
VMEbus in order to design boards that deliver top performance. Recommendations 
found in this document are based on this kind of experience, and are provided to 
designers to speed their traversal of the learning curve. 

SUGGESTION chapter.number: 

in the VMEbus specification, a suggestion contains advice which is helpful but not 
vital. The reader is encouraged to consider the advice before discarding it. Some 
design decisions that need to be made in designing VMEbus boards are difficult until 
experience has been gained with the VMEbus. Suggestions are included to help a 
designer who has not yet gained this experience. Some suggestions have to do with 
designing boards that can be easily reconfigured for compatibility with other boards, or 
with designing the board to make the job of system debugging easier. 

PERMISSION chapter«number: 

In some cases a VMEbus rule does not specifically prohibit a certam design approach, 
but the reader might be left wondering whether that approach might violate the spirit of 
the rule, or whether it might lead to some subtle problem. Permissions reassure the 
reader that a certain approach is acceptable, and will cause no problems. The upper- 
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case word MAY is reserved exclusively for stating permissions in this document and is 
not used for any other purpose. 

OBSERVATION chapter.number: 

Observations do not offer any specific advice. They usually follow naturally from what 
has just been discussed. They spell out the implications of certain VMEbus rules and 
bnng attention to things that might otherwise be overlooked. They also give the 
rationale behind certain rules, so that the reader understands why the rule must be 
followed. 

1.4.1 Signal Line States 

The VMEbus specification describes its protocol in terms of levels and transitions on 
bus lines. 

A signal line is always assumed to be in one of two levels or in transition between 
these levels. Whenever the term "high" is used, it refers to a high TTL voltage level 
The term "low" refers to a low TTL voltage level. A signal line is "in transition" when its 
voltage is moving between these levels. (See Chapter 6 for voltage thresholds used 
on the VMEbus.) 

There are two possible transitions which can appear on a signal line, and these are 
called "edges". A rising edge is the time during which a signal level makes its 
transition from a low level to a high level. The falling edge is the time during which a 
signal level makes its transition from a high level to a low level. 

Some bus specifications prescribe maximum or minimum rise and fall times for these 
edges. The problem with doing this is that board designers have very little control over 
these times. If the backplane is heavily loaded, the rise and fall times will be long. If it 
IS lightly loaded, these times might be short. Even if designers know what the 
maximum and minimum loading will be, they still need to spend time in the lab, 
experimenting to find out which drivers will provide the needed rise and fall times. 

In fact, rise and fall times are the result of a complex set of interactions involving the 
signal line impedances of the backplane, Its terminations, the source impedance of the 
dnvers, and the capacitive loading of the signal line. In order to trade off all of these 
factors the board designer would have to study transmission line theory, as well as 
certain specific parameters of drivers and receivers which are not normally found in 
most manufacturers data sheets. 

Recognizing all of this, the VMEbus standard doesn't specify rise and fall times. 
Instead, it specifies the electrical characteristics for drivers and receivers and suggests 
how to design the backplane. It also tells designers how the worst case bus loading 
will affect the propagation delay of these drivers so that they can ensure that the 
VMEbus timing is met before building a board. If VMEbus designers follow these 
propagation delay guidelines, their boards will operate reliably with other VMEbus 
compatible boards under worst case conditions. 
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1.4.2 Use Of The Asterisk n BB 

To help define usage, signal mnemonics have an asterisk suffix where required: H 

a. An asterisk (*) following the signal name of signals which are level significant 
denotes that the signal is true or valid when the signal is low. 

b. An asterisk (*) following the signal name of signals which are edge significant 
denotes that the actions initiated by that signal occur on a high to low transition. 

OBSERVATION 1.1: 

The asterisk is inappropriate for the asynchronously running clock lines SYSCLK and 
SERCLK. There is no fixed phase relationship between these clock lines and other 
VMEbus timing. 

1.5 PROTOCOL SPECIFICATION 

There are two layers of VMEbus protocol. The lowest VMEbus layer called the 
backplane access layer, is composed of the backplane interface logic, the Utility Bus 
modules, and the Arbitration Bus modules. The VMEbus's data transfer layer, is j 
composed of the Data Transfer Bus and Priority Interrupt Bus modules. Figure 1-2 1 
shows this layering. 

OBSERVATION 1.2: 

The signal lines used by the data transfer layer modules form a special class because 
they are driven by different modules at different times. They are driven with line drivers 
that can be turned on and off at each board, based upon signals generated in the 
backplane access layer. It is very important that their turn-on and turn-off times be 
carefully controlled to prevent two drivers from attempting to drive the same signal line 
to different levels. Special timing diagram notation is used in this document to specify 
their turn-on and turn-off times. It is shown in Figure 1-3. 

There are two basic kinds of protocol used on the VMEbus: closed loop protocols and 
open loop protocols. Closed loop protocols use interlocked bus signals while open 
loop protocols use broadcast bus signals. 

1.5-1 Interlocked Bus Signals 

An interlocked bus signal is sent from a specific module to another specific module. 
The signal is acknowledged by the receiving module. An interlocked relationship 
exists between the two modules until the signal is acknowledged. 

For example, an INTERRUPTER can send an interrupt request which is answered later 
with an interrupt acknowledge signal (no time limit is prescribed by the VMEbus 
specification). The INTERRUPTER doesn't remove the interrupt request until the 
INTERRUPT HANDLER acknowledges it. 
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Figure 1-3. Signal Timing Notation 

Interlocked bus signals coordinate internal functions of the VMEbus system, as 
opposed to interacting with external stimuli. Each interlocked signal has a source 
module and a destination module within the VMEbus system. 

The address strobe and data strobes are especially important interlocking signals. 
They are interlocked with the data ;transfer acknowledge and bus error signals and 
coordinate the transfer of addresses and data which are the basis for all information 
flow between modules in the data transfer layer. 

1.5.2 Broadcast Bus Signal 

A module generates a broadcast signal in response to an event. There is no protocol 
for acknowledging a broadcast signal. Instead, the broadcast is maintained for a 
minimum specified time, long enough to assure that all appropriate modules detect the 
signal. Broadcast signals might be activated at any time, irrespective of any other 
activity taking place on the bus. They are each sent over a dedicated signal line. Some 
examples are the system reset and AC failure lines. These signal lines are not sent to 
any specific module, but announce special conditions to all modules. 
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1.6 SYSTEM EXAMPLES AND EXPLANATIONS 



A protocol specification describes, in detail, the behavior of the various functional 
modules. It discusses how a module responds to a signal without saying where the 
signal came from. Because of this, a protocol specification does not give the reader a 
complete picture of what is going on over the bus. To help the reader, the VMEbus 
specification provides examples of typical VMEbus operations. Each example shows 
one possible sequence of events: other sequences are also possible. In providing 
these examples, there is the danger that readers will assume that the sequence shown 
in the example is the only legal one. To help readers avoid this trap, all examples are 
given in a narrative style, using the present tense. This is in contrast to the imperative 
style used when giving rules for compliance with the VMEIdus specification. 
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CHAPTER 2 
DATA TRANSFER BUS 

2.1 INTRODUCTION 

The VMEbus includes a high speed asynchronous parallel Data Transfer Bus (DTB). 
Figure 2-1 shows a typical VMEbus system, including all of the DTB functional module 
types. MASTERS use the DTB to select storage locations provided by SLAVES, and 
to transfer data to or from those locations. Some MASTERS and SLAVES use all of 
the DTB lines, while others use only a subset. 

LOCATION MONITORS monitor data transfers between MASTERS and SLAVES. 
When an access is done to one of the byte location(s) that it monitors, a LOCATION 
MONITOR generates an on-board signal. For example. It might signal its on-board 
processor by means of an interrupt request. In such a configuration, if processor board 
A writes into a location of the global VMEbus memory that is monitored by processor 
B's LOCATION MONITOR, processor B will be interrupted. 

After a MASTER initiates a data transfer cycle it waits for the responding SLAVE to 
respond before finishing the cycle. The asynchronous definition of the VMEbus allows 
a SLAVE to take as long as it needs to respond. If a SLAVE fails to respond because 
of some malfunction, or if the MASTER accidentally addresses a location where there 
is no SLAVE, the BUS TIMER intervenes, allowing the cycle to be terminated. 

2.2 DATA TRANSFER BUS LINES 

The Data Transfer Bus lines can be grouped into three categories: 



E 



dressing lines 


Data lines 


Control lines 


A01-A31 


D00-D31 


AS* 


AM0-AM5 




DSO* 


DSO* 




DS1* 


DS1* 




BERR* 


LWORD* 




DTACK* 
WRITE* 



OBSERVATION 2.1: 

The two data strobes (DSO* and DSr) serve a dual function: 

a. The levels of these two data strobe lines are used to select which byte(s) are 
accessed. 

b. The edges of the data strobes are also used as tihiing signals which coordinate the 
transfer of the data between the MASTER and SLAVE. 
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Figure 2-1 . Data Transfer Bus Functional Block Diagram 



DATA TRANSFER 



2.2,1 Addressing Lines 



The smallest addressable unit of storage is the byte location. Each byte location is 
assigned a unique binary address. Each byte location can be assigned to one of four 
categories, according to the the least significant two bits of its address. (See Table 2-1) 



Table 2-1. The Four Categories Of Byte Locations 






Category 



Byte address 



BYTE(O) 
BYTE(1) 
BYTE{2) 
BYTE(3) 



xxxxxx xxxxxxoo 

XXXXXX XXXXXX01 

xxxxxx XXXXXX10 

xxxxxx XXXXXX11 



A set of byte locations whose addresses differs only in the two least significant bits, is 
called a 4-byte group or a BYTE(0-3) group. Some, or all of the bytes in a 4-byte 
group can be accessed simultaneously by a single DTB cycle. 

MASTER^ use address lines A02-A31 to select which 4-byte group will be accessed. 
Four additional lines (DS1*, DSO*, A01, and LWORD*) are then used to select which 
byte location (s) within the 4-byte group are accessed during the data transfer. Using 
these four lines, a MASTER can access 1, 2, 3, or 4-byte locations simultaneously, 
depending upon the type of cycle. The 34 possible cycle types with the corresponding 
levels of these four lines are listed in Table 2-2 . 

OBSERVATION 2.2: 

In cycles where both data strobes are driven low, one data strobe might go low slightly 
after the other. In this case the signal levels indicated in Table 2-2 are the final levels. 

OBSERVATION 2.3: 

Given the 4 signal line levels shown in Table &-2, there are 16 possible combinations 
of levels. Of these 16, there are two illegal combinations that are not used (see Table 
in RULE 2.1). 



RULE 2.1: 

MASTERS MUST NOT generate DTB cycles where the final levels of DSO*, 

A01 , and LWORD* are either of the following illegal combinations: 



DS1*, 
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I 



PERMISSION 2.1: 

MASTERS that generate BYTE(1-2) READ or BYTE(1-2) WRITE cycles MAY generate 
either of the two combinations described in RULE 2.1 briefly as transition states (i.e. 
while one data strobe has fallen, but the other has not). 

OBSERVATION 2.4: 

Whenever a MASTER drives LWORD* low and A01 high it drives both data strobes 
low. (Any other combination is illegal.) VMEbus board designers can take advantage 
of this to simplify the logic on SLAVES. 

PERMISSION 2.2: 

To simplify the required logic, SLAVES which respond to BYTE(1-2) READ and 
BYTE(1-2) WRITE cycles MAY be designed without logic to distinguish between these 
cycles and the two illegal cycles described in RULE 2.1 . 



Table 2-2. Signal Levels Used To Select Which Byte Location(s) 
Are Accessed During A Data Transfer 



Type of cycle 


DS1* 


DSO* 


A01 


LWORD* 


ADDRESS-ONLY 


high 


high 


< — -Notel — — -> 


Single even byte transfers 

BYTE(O) READ or WRITE 
BYTE(2) READ or WRITE 


low 
low 


high 
high 


low 
high 


high 
high 


Single odd byte transfers 

BYTE(1) READ or WRITE 
BYTE(3) READ or WRITE 


high 
high 


low 
low 


low 
high 


high 
high 


Double byte transfers 

BYTE(O-I) READ or WRITE 
BYTE(2-3) READ or WRITE 


low 
low 


low 
low 


low 
high 


high 
high 


Quad byte transfers 
BYTE(0-3) READ or WRITE 


low 


low 


low 


low 
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Table 2-2. Signal Levels Used To Select Which Byte Location(s) 
Are Accessed During A Data Transfer (cont'd) 



Type Of cycle 



DS1 



DSO* A01 LWORD* 



Single byte block transfers 

SINGLE BYTE BLOCK READ or WRITE 



-Note 2- 



Quad byte block transfers 

QUAD BYTE BLOCK READ or WRITE 



Single byte RMW transfers 

BYTE(O) READ-MODIFY-WRITE 
BYTE(1) READ-MODIFY-WRITE 
BYTE(2) READ-MODIFY-WRITE 
BYTE(3) READ-MODIFY-WRITE 



Unaligned transfers 

BYTE(0-2) READ or WRITE 
BYTE(1-3)READorWRITE 
BYTE(1-2)READorWRITE 



low 



low 
high 
low 
high 



Double byte RMW transfers 

BYTE(0-1 ) READ-MODIFY-WRITE low 

BYTE(2-3) READ-MODIFY-WRITE low 



Quad byte RMW transfers 

BYTE(0-3) READ-MODIFY-WRITE low 



low 
high 
low 



low 



high 
low 
high 
low 



low 
low 



low 



high 
low 
low 



low 



low 
low 
high 
high 



low 
high 



low 



low 
low 
high 



high 



Double byte block transfers 

DOUBLE BYTE BLOCK READ or WRITE low low Note 3 high 



low 



I 



high 
high 
high 
high 



high 
high 



low 



low 
low 
low 
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Table 2-2. Signal Levels Used To Select Which Byte Location(s) 
Are Accessed During A Data Transfer (cont'd) 

Notes: 

1. During ADDRESS-ONLY cycles, both data strobes are maintained high, but 
the A01 and LWORD* lines might be either high or low. 

2. During single byte block transfers, the two data strobes are alternately driven 
low. Either data strobe might be driven low on the first transfer. If the first 
accessed byte location is BYTE(O) or BYTE(2), then DS1* is driven low first. If 
the first accessed byte location is BYTE(1) or BYTE(3), then DSO* is driven low 
first. A01 is valid only on the first data transfer (i.e. until the SLAVE drives 
DTACK* or BERR* low the first time) and might be either high or low depending 
upon which byte the single byte block transfer begins with. If the first byte 
location is BYTE(O) or BYTE(1), then A01 is low. If the first byte location is 
BYTE(2) or BYTE(3), then A01 is high. 

An example of a Single byte block transfer cycle which starts with BYTE(2) is 
given below: 





DS1* 


DSO* 


A01 LWORD* 


First data transfer BYTE (2) 
1 BYIh(3) 
1 BYIb(O) 
i BYTE(1) 

Last data transfer BYTE (2) 


low 
high 
low 
high 
low 


high 
low 
high 
low 
high 


high high 
X X 
X X 
X X 
X X 








X=highorlow. 



3. During a Double byte block transfer, the two data strobes are both driven low 
on each data transfer. A01 is valid only on the first data transfer (i.e. until the 
SLAVE drives DTACK* or BERR* low the first time) and might be either high or 
low depending upon what double byte group the double byte block transfer 
begins with. If the first double byte group is BYTE(0-1), then A01 is low. If the 
first double byte group is BYTE(2-3), then A01 is high. 

An example of a Double byte block transfer cycle which starts with BYTE(2-3) is 
given below: 





DS1* 


DSO* 


A01 LWORD* 


First data transfer BYTE (2-3) 
1 BYTE (0-1) 
1 BYTE (2-3) 

Last data transfer BY 1 h (0-1 ) 


low 
low 
low 
low 


low 
low 
low 
low 


high high 
X X 
X X 
X X 








X = high or low. 
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2.2.2 Address Modifier Lines 

There are 6 address modifier lines. They allow the MASTER to pass additional binary 
information to the SLAVE during data transfers. Table 2-3 lists all of the 64 possible 
address modifier (AM) codes and classifies each into one of three categories: 

Defined 
Reserved 
User defined 

The defined address modifier codes can be further classified into three categories: 

Short addressing AM codes indicate that address lines A02-A15 are being used 
to select a BYTE(0-3) group. 

Standard addressing AM codes indicate that address lines A02-A23 are being 
used to select a BYTE (0-3) group. 

Extended addressing AM codes indicate that address lines A02-A31 are being 
used to select a BYTE (0-3) group. 

RULE 2.2: 

Except for the User defined codes, the codes defined in Table 2-3 MUST NOT be 
used for purposes other than those specified. 

RULE 2.3: 

VMEbus SLAVE boards MUST NOT respond to reserved address modifier codes. 

OBSERVATION 2.5: 

Reserved address modifier codes are for future enhancements. If SLAVE boards 
respond to these codes, incompatibilities might result at some future date, when usage 
of these codes is defined. 

PERMISSION 2.3: 

User defined codes MAY be used for any purpose which board vendors or board 
users deem appropriate (page switching, memory protection, MASTER or task 
identification, privileged access to resources, etc.) 



I 
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Table 2-3. Address Modifier Codes 



i 





ADDRESS MODIFIER 




HEX 
CODE 


5 


4 


3 


2 


1 





FUNCTION 


3F 
3E 
3D 
30 


H 
H 
H 
H 


H 
H 
H 
H 


H 
H 
H 
H 


H 
H 
H 
H 


H 
H 
L 
L 


H 

L 
H 
L 


Standard Supervisory B!ocl< Transfer 
Standard Supervisory Program Access 
Standard Supervisory Data Access 
Reserved 


3B 
3A 
39 
38 


H 
H 
H 
H 


H 
H 
H 
H 


H 
H 
H 
H 


L 
L 
L 
L 


H 
H 

L 
L 


H 

L 
H 
L 


Standard Non-Privileged Block Transfer 
Standard Non-Privileged Program Access 
Standard Non-Privileged Data Access 
Reserved 


37 


H 


H 


L 


H 


H 


H 


Reserved 


36 


H 


H 


L 


H 


H 


L 


Reserved 


35 


H 


H 


L 


H 


L 


H 


Reserved 


34 


H 


H 


L 


H 


L 


L 


Reserved 


33 


H 


H 


L 


L 


H 


H 


Reserved 


32 


H 


H 


L 


L 


H 


L 


Reserved 


31 


H 


H 


L 


L 


L 


H 


Reserved 


30 


H 


H 


L 


L 


L 


L 


Reserved 


2F 


H 


L 


H 


H 


H 


H 


Reserved 


2E 


H 


L 


H 


H 


H 


L 


Reserved 


2D 
20 


H 
H 


L 

L 


H 
H 


H 
H 


L 
L 


H 
L 


Short Supervisory Access 
Reserved 


2B 


H 


L 


H 


L 


H 


H 


Reserved 


2A 


H 


L 


H 


L 


H 


L 


Reserved 


29 
28 


H 
H 


L 

L 


H 
H 


L 

L 


L 
L 


H 

L 


Short Non-Privileged Access 
Reserved 


27 


H 


L 




H 


H 


H 


Reserved 


26 


H 


L 




H 


H 


L 


Reserved 


25 


H 


L 




H 


L 


H 


Reserved 


24 


H 


L 




H 


L 


L 


Reserved 


23 


H 


L 




L 


H 


H 


Reserved 


22 


H 


L 




L 


H 


L 


Reserved 


21 


H 


L 




L 


L 


H 


Reserved 


20 


H 


L 




L 


L 


L 


Reserved 



L = low signal level H = high signal level 
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Table 2-3. Address Modifier Codes (cont'd) 



HEX 
CODE 



ADDRESS MODIFIER 
5 4 3 2 1 



FUNCTION 



E 



1F 
1E 
1D 
1C 
1B 
1A 
19 
18 



17 
16 
15 
14 
13 
12 
11 
10 



OF 
OE 
OD 
OC 
OB 
OA 
09 
08 



07 
06 
05 
04 
03 
02 
01 
00 



H H H H H 

H H H H L 

H H H L H 

H H H 

H H L 

H H L 

H H L 

H H L 



L L 

H H 

H L 

L H 

L L 



L 
L 
L 
L 
L 
L 
L 
L 



H 
H 
H 
H 
H 
H 
H 
H 



H H H 

H H L 

H L H 

H L L 

H H 

H L 

L H 

L L 



L 
L 
L 

L 



L 

L 
L 
L 
L 
L 
L 
L 



H H H H 
H H H L 
H H L H 



H H 

H L 

H L 

H L 

H L 



L L 

H H 

H L 

L H 

L L 



L 
L 

L 
L 
L 

L 
L 
L 



L 
L 
L 
L 
L 
L 
L 
L 



H H H 
H H L 



L H 

L L 

H H 

H L 

L H 

L L 



User defined 
User defined 
User defined 
User defined 
User defined 
User defined 
User defined 
User defined 



User defined 
User defined 
User defined 
User defined 
User defined 
User defined 
User defined 
User defined 



Extended Supervisory Blocl< Transfer 
Extended Supervisory Program Access 
Extended Supervisory Data Access 
Reserved 

Extended Non-Privileged Blocl< Transfer 
Extended Non-Privileged Program Access 
Extended Non-Privileged Data Access 
Reserved 



Reserved 
Reserved 
Reserved 
Reserved 
Reserved 
Reserved 
Reserved 
Reserved 



L = low signal level 



H = high signal level 
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RECOMMENDATION 2,1: 

To allow VMEbus users to tailor the use of the user defined address modifier codes to 
their own needs, decode them in a flexible way on SLAVE boards. Users can then 
configure the board to give any decoding required by their system. 

OBSERVATION 2.6: 

Socketed PROMS and FPLAS provide a flexible way for decoding the address 
modifier codes, 

SUGGESTION 2.1: 

Where SLAVES are manufactured with a programmed device (e.g. a PROM or a 
FPLA) installed in the socket, program the device so that the SLAVE responds to the 
following AM codes: 

A16 SLAVES with D08(O). D08(EO), D16, or D32 capability: 29, 2D 

A24 SLAVES with D08(O), D08(EO), D16, or D32 capability: 39, 3A, 3D, and 3E 

A32 SLAVES with D08(O), D08(EO), D16, or D32 capability: 09, OA, OD, and OE 

A24 SLAVES with BLT capability: 3B, 3F 

A32 SLAVES with BLT capability: OB, OF 

The mnemonics A1S, A24, and A32 are defined in Table 2-9. The mnemonics D08(O). 
D08(EO), D16, D32, and BLT are defined in Tables 2-10, and 2-11. 

2.2.3 Data Lines 

VMEbus systems can be built with a backplane configuration that provides either 16 
data lines (D00-D15), or 3? data lines (D00-D31). Backplane configurations that 
provide 16 data lines allow a MASTER to access only two byte locations 
simultaneously, while those with 32 data lines allow up to four byte locations to be 
accessed. When the MASTER has selected 1, 2, 3, or 4 byte locations, using the 
method described in Section 2.2.1, it can transfer binary data between itself and those 
locations over the data bus. Table 2-4 shows how the data lines are used to move 
data during each of the 34 cycle types. 

PERMISSION 2.4: 

The data sender (MASTER for a write cycle; SLAVE for a read cycle) may drive data 
lines which are not used to transfer data. 
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Table 2-4. Use Of The Data Lines To Move Data During Each Of The 34 Cycle Types 



During the following 
types of cycles... 



the data lines are used to transfer 
data as shown below: 

D24-D31 D16-D23 D08-D15 D00-D07 



ADDRESS-ONLY 



no bytes transferred 



Single even byte transfers 

BYTE{0) READ or WRITE 
BYTE(2) READ or WRITE 



BYTE(O) 
BYTE(2) 



Single odd byte transfers 

BYTE(1) READ or WRITE 
BYTE(3) READ or WRITE 



Double byte transfers 

BYTE(0-1 ) READ or WRITE 
BYTE(2-3) READ or WRITE 



BYTE(O) 
BYTE(2) 



Single byte block transfers 

SINGLE BYTE 

BLOCK READ or WRITE 



I 



BYTE(1) 
BYTE{3) 



BYTE(1) 
BYTE(3) 



Quad byte transfers 

BYTE(0-3) READ or WRITE BYTE(O) BYTE(1) BYTE(2) BYTE{3) 



Note 1 



Double byte block transfers 

DOUBLE BYTE 
BLOCK READ or WRITE 



Note 2 



25 



DATA TRANSFER 



I 



Table 2-4. Use Of The Data Lines To Move Data During 
Each Of The 34 Cycle Types (cont'd) 



During the following 
types of cycles... 



Quad byte block transfers 

QUAD BYTE 

BLOCK READ or WRITE 



Single byte RMW transfers 

BYTE(O) 

READ-MODIFY-WRITE 
BYTE(1) 

READ-MODIFY-WRITE 
BYTE(2) 

READ-MODIFY-WRITE 
BYTE(3) 

READ-MODIFY-WRITE 



Double byte RMW transfers 

BYTE(0-1) 

READ-MODIFY-WRITE 
BYTE(2-3) 

READ-MODIFY-WRITE 



Quad byte RMW transfers 

BYTE(0-3) 
READ-MODIFY-WRITE 



Unaligned transfers 

BYTE(0-2) READ or WRITE 
BYTE(1-3) READ or WRITE 
BYTE(1-2) READ or WRITE 



the data lines are used to transfer 
data as shown below: 

D24-D31 D16-D23 D08-D15 D00-D07 



BYTE(O) BYTE(1) BYTE(2) BYTE(3) 



BYTE(O) BYTE(1) 



BYTE(O) 



BYTE(1) 
BYTE(1) 
BYTE(1) 



BYTE(O) 



BYTE(2) 



BYTE(1) 



BYTE(3) 



BYTE(O) 
BYTE(2) 


BYTE(1) 
BYTE(3) 


BYTE(2) 


BYTE(3) 


BY 1 h(2) 
BYTE(2) 
BY 1 b(2) 


BYTE(3) 
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Table 2-4. Use Of The Data Lines To Move Data During 
Each Of The 34 Cycle Types (confcl) 



Notes: 



1. During Single byte block transfers, data is transferred 8 bits at a time over 
D00-D07 or D08-D15. One example of this is given below: 



I 



D24-D31 D16-D23 D08-D15 D00-D07 



First data transfer 



BYTE(2) 
BYTE{0) 
BYTE{2) 



Last data transfer 



BYTE{1) 
BYTE(3) 
BYTE(1) 
BYTE(3) 



2. During a Double byte block transfer, data is transferred 16 bits at a time over 
D00-D15. One example of this is given below: 



D24-D31 D16-D23 D08-D15 D00-D07 



First data transfer 
I 
I 

i 

Last data transfer 



BYTE(2) 
BYTE(O) 
BYTE(2) 
BYTE(O) 
BYTE{2) 
BYTE(O) 



BYTE(3) 
BYTE(1) 
BYTE(3) 
BYTE{1) 
BYTE(3) 
BYTE(1) 
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2.2.4 Data Transfer Bus Control Lines 

The following signal lines are used to control the movement of data over the data 



transfer lines: 



AS* Address Strobe 

DSO* Data Strobe Zero 

DS1* Data Strobe One 

BERR* Bus Error 

DTACK* Data Transfer Acknowledge 

WRITE* ReadWrite 



2.2.4.1 AS* 

A falling edge on this line informs all SLAVE modules that the address is stable and 
can be captured. 

2.2.4.2 DSO* And DS1* 

In addition to their function in selecting byte locations for data transfer, as described in 
bection 2.2.1 , the data strobes also serve additional functions. On write cycles the first 
data strobe falling edge indicates when the MASTER has placed valid data on the 
data bus. On read cycles, the first rising edge tells the SLAVE when it can remove 
valid data from the data bus. 

OBSERVATION 2.7: 

VMEbus MASTERS are not permitted to drive either of the data strobes low before 
dnving AS* low. However, due to the fact that AS* might be more heavily loaded on 
the backplane than the data strobes, SLAVES and LOCATION MONITORS might 
detect a falling edge on a data strobe, before they detect the falling edge on AS*. 

PERMISSION 2.5: 

VMEbus SLAVES and LOCATION MONITORS MAY be designed to capture the 
i/if^ ^ ^^^^ ^®*®^* ^ *^"'"9 ^"^9® °" ^ <^^*3 strobe instead of on the falling edge 

OT Mo . / 

OBSERVATION 2.8: 

VMEbus SLAVES and LOCATION MONITORS that capture the address on the fallinq 
edge of the data strobe(s) need not monitor AS*. 

OBSERVATION 2.9: 

In order to take full advantage of address pipelining as described in Section 2 4 2 or 
fallSf ^ed^e^'Ms'^^^ ^"^ ^"^^ ^^'^'®^' ^ ^'"^^^ ^^°"'^ capture the address' on the 



28 



DATA TRANSFER 



2.2.4.3 DTACK* 



The SLAVE drives DTACK* low to indicate that it has successfully received the data on 
a write cycle. On a read cycle, the SLAVE drives DTACK* low to indicate that it has 
placed data on the data bus. 

2.2.4.4 BERR* 

BERR* is driven low by the SLAVE or by the BUS TIMER to indicate to the MASTER 
that the data transfer was unsuccessful. For example, if a MASTER tnes to write to a 
location which contains Read-Only Memory, the responding SLAVE might dnve 
BERR* low If the MASTER tries to access a location that is not provided by any 
SLAVE, the BUS TIMER would drive BERR* low after waiting a specified penod. 

OBSERVATION 2.10: . ^,,,^^ ^ ,^ 

The BERR* line is a convenience which is useful when debugging VMEbus systems. It 
also allows system failures to be detected quickly during normal operation. Not all 
VMEbus systems will need this capability. 

PERMISSION 2.6: ^ ^^^^^ 

VMEbus SLAVES MAY be designed without a driver for BERR . 

SUGGESTION 2.2: , . , . . 

Design SLAVES to respond with a falling edge on BERR* in the following situations: 

a When a D08{O), D08{EO), or D16 SLAVE is requested to do a quad byte cycle. 

b" When a D08(O) or D08{EO) SLAVE is requested to do a double byte cycle. 

When a non-UAT SLAVE is requested to do an unaligned transfer, (i.e. A tnple 

" byte transfer or a double byte BYTE(1 -2) transfer.) 
d. When a SLAVE detects an uncorrectable error in the data it retneves from its 
internal storage during a read cycle. 

The mnemonics D08{O), D08(EO), D16, and UAT are defined in Tables 2-10 and 2-15. 

RULE 2 4" 

D08{O) D08(EO), and D16 SLAVES MUST MOT respond with a falling edge on 
DTACK* during a quad byte cycle if they do not have quad byte capability. 

RULE 2 5" 

D08(O) and"D08(EO) SLAVES MUST NOT respond with a falling edge on DTACK* 
during a double byte cycle if it does not have double byte capability. 

RULE 2 6" 

A SLAVe'mUST NOT respond with a falling edge on DTACK* during an unaligned 

transfer cycle, if it does not have UAT capability. 



i 
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2.2.4.5 WRITE* 



WRITE* is a level significant signal line strobed by the falling edge of the first data 

aWhP^n wmTP*^'^ ^l^^^ 'y^^'^P *° '"^'°^*« *^^ d''^^»'°" °f data t?lns er opeStionl 
^^^nw^!^^- 'T' ^K^T *'^"^^^'' ^'■•■^^*'°" 's from the MASTER to the 
th^MASTER '^ ^^^' ^''^ ''^^^ *''^"^^®'' ^'■'®^*'°" '^ ^^°"^ the SLAVE to 

2.3 DTB MODULES - BASIC DESCRIPTION 

ivnlfS *° *1® ADDRESS-ONLY cycle, the DTB protocol defines 33 different cycle 
types that can be used to transfer data. Each of these 34 cycle types can be used n 
any of three addressing modes: short (16-bit), standard (24- bit), and extended (32-bi« 
The capabilities of MASTERS. SUWES and LOCATION MONITORS are described by 

i?DeSivT7Thf.'w5itfr t^i"^"'" *yP.^^ *^^y ^^" 9^"^^^t«- accept, 0? monito'r 
respectively. (This will be descnbed in more detail later in this chapter.) 

Sections 2.3 1 through 2.3.4 provide block diagrams for the four tvoes of DTB 
functional modules: MASTER, SLAVE, LOCATION MONITOR, and Ss TIMER 



RULE 2.7: 



Output signal lines shown with solid lines in Figures 2-2 through 2-5 MUST be driven 
by the module, unless it would always drive them high. 

OBSERVATION 2.11: 

IF an output signal line is not driven, 

THEN terminators on the bacl<plane ensure that it is high. 

RULE 2.8: 

Input signal lines shown with solid lines in Figures 2-2 through 2-5 MUST be 
monitored and responded to in the appropriate fashion. "gn ^ o iviui, i oe 

OBSERVATION 2.12: 

i?nP^^?Flnnrrf ?9 S^'^^K^o^^' "^"^'"^ ^"^ ^"0^'toring Signal lines shown with dotted 
lines in Figures 2-2 through 2-5 are given in Tables 2-5, 2-6, and 2-8. 

2.3.1 MASTER 

Itiat^'L'^'^^'^"' ,°' *u® MASTER is shown in Figure 2-2. The dotted lines in the 
diagram show signals whose use varies among the various types of MASTERS Table 
2-5 specifies how the various types of MASTERS use these lines. Further information 

fwORD*''n?n*''fnH nVri'®" °^ MASTERS drive the address lines, the data lines, 
LWOHD , DSO , and DS1 is given in Tables 2-1 9, 2-20, 2-21 . 
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Figure 2-2. Block Diagram: MASTER 
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Table 2-5. RULES And PERMISSIONS That Spesify The Use of The Dotted 
Lines By The Various Types of MASTERS 



Type of 
MASTER 



D16 



D32 



A16 



A24 



A32 



ALL 



Notes: 



Use of dotted lines 



D08(EO) MUST drive DSO* and DSr, but not both low on the same 

data transfer. 
MUST monitor and drive D00-D1 5 
MUST NOT drive lACK* low. 

MAY or MAY not drive LWORD*. 

MAY or MAY not drive or monitor D1 6-D31 . 



MUST drive DSO* and DS1 *. 
MUST monitor and drive D00-D1 5. 
MUST NOT drive lACK* low. 

MAY or MAY not drive LWORD*. 

MAY or MAY not drive or monitor D16-D31 . 



MUST drive DSO*, DS1 *, and LWORD*. 
MUST monitor and drive D00-D31 . 
MUST NOT drive lAGK* low. 



MUST drive A01-A1 5. 

MAY or MAY not drive A1 6-A31 



MUST drive A01-A23. 

MAY or MAY not drive A24-A31 



MUST drive A01-A31. 



MAY or MAY not monitor BGLR*, or AGFAIL* 
(see Chapters 3 and 5). 



1. The mnemonics D08(EO), D16, and D32 are defined in Table 2-10. 

2. The mnemonics A16, A24, and A32 are defined in Table 2-9. 
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2.3.2 SLAVE 

The block diagram of the SLAVE is shown in Figure 2-3. The dotted lines in the 
diagram show signals whose use varies among the various types of SLAVES. Table 
2-6 shows how the various types of SLAVES use these lines. Further information 
about how the various types of SLAVES drive the data lines is given in Table 2-22. 
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Figure 2-3. Block diagram: SLAVE 
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Table 2-6. RULES And PERMISSIONS That Specify The Use Of The 
Dotted Lines By The Various Types Of SLAVES 



B 



Type of 
SLAVE 



D16 



D32 



A16 



A24 



A32 



ALL 



Notes: 



Use of dotted lines 



D08(O) MUST monitor and drive D00-D07. 

MAY or MAY not monitor AS*. 

MAY or MAY not monitor or drive D08-D31 . 



D08(EO) MUST monitor and drive D00-D15. 

MAY or MAY not monitor AS*. 

MAY or MAY not monitor or drive D16-D31. 



MUST monitor and drive D00-D15. 

MAY or MAY not monitor AS*. 

MAY or MAY not monitor or drive D16-D31 . 



MUST monitor and drive D00-D31 . 
MAY or MAY not monitor AS*. 



MUST monitor A01-A1 5. 

MAY or MAY not monitor A1 6-A31 . 



MUST monitor A01-A23. 

MAY or MAY not monitor A24-A31 . 



MUST monitor A01 -A31 . 



MAY or MAY not drive BERR*. 



1. The mnemonics D08(O), D08(EO), D16, and D32 are defined in Table 2-10 

2. The mnemonics A1 6, A24, and A32 are defined in Table 2-9. 
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2.3.3 BUS TIMER 

The block diagram of the BUS TIMER is shown in Figure 2-4. BUS TIMERS can be 
designed to drive BERR* low after various periods of time. Table 2-7 shows how the 
BTO{ ) mnemonic is used to describe the various types of BUS TIMERS. 

OBSERVATION 2.13: . „ . ■ , » dmo 

The dotted DTACK* and BERR* lines shown in Figure 2-4 allow to implement a BUS 
TIMER in one of two ways: , . , ... .u u 

a To drive BERR* low when the first data strobe stays low for longer than the bus 

time-out period, regardless of the levels on the DTACK* and BERR* lines. 
b To drive BERR* low when the first data strobe stays low for longer than the bus 
time-out period, but only if both DTACK* and BERR* are high at the point of 
time-out. 



B 



Table 2-7. Use Of The BTO( ) Mnemonic To Specify The 
Time-Out Period Of BUS TIMERS 



The 
Following 
Mnemonic 



When 
Applied 
to a 



Means that it 



BTO(x) BUS TIMER drives BERR* low if the first data strobe stays 

low for longer than x microseconds. 
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Figure 2-4. Block Diagram: BUS TIMER 



36 



DATA TRANSFER BUS 



2.3.4 LOCATION MONITOR 

The block diagram of the LOCATION MONITOR is shown in Figure 2-5. The clotted 
lines in the diagram show signals whose use varies among the vanous types o 
LOCATION MONITORS. Table 2-8 shows how the various types of LOCATION 
MONITORS use these lines. 
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Figure 2-5. Block Diagram: LOCATION MONITOR 
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Table 2-8. RULES and PERMISSIONS That Specify The Use Of The Dotted 
Lines By The Various Types Of LOCATION MONITORS 



a 



Type of 

LOCATION Use of clotted lines 

MONITOR 



^^ ^ MUST monitor A01 -A1 5. 

MAY or MAY not monitor A1 6-A31 . 



A24 MUST monitor A01 -A23. 

MAY or MAY not monitor A24-A31 . 



A32 MUST monitor A01 -A31 . 



ALL MAY or MAY not monitor AS* 



Note: 



The mnemonics A16. A24, and A32 are defined in Table 2-9. 
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2.3.5 Addressing Modes 

MASTERS broadcast an address over the DTB at the beginning of each cycle. This 
broadcasted address might be a 16, 24 or 32-bit address, depending upon the 
capabilities of the MASTER broadcasting it. The 16-bit addresses are "short 
addresses", the 24-bit addresses are "standard addresses", and the 32-bit addresses 
are "extended addresses". 

Table 2-9 shows the various mnemonics used to describe the addressing capabilities, 
and how each is used to describe MASTERS, SLAVES, and LOCATION MONITORS. 



B 



Table 2-9. Mnemonics That Specify Addressing Capabilities 



The When 

Following Applied 
Mnemonic to a 



A16 



A24 



A32 



MASTER 

SLAVE 

LOCATION 
MONITOR 



MASTER 

SLAVE 

LOCATION 
MONITOR 



MASTER 

SLAVE 

LOCATION 
MONITOR 



Means that it 



can generate cycles with short(16 bit) addresses, 
can accept cycles with short (16 bit) addresses 
can monitor cycles with short (16 bit) addresses. 



can generate cycles with standard (24 bit) addresses, 
can accept cycles with standard (24 bit) addresses, 
can monitor cycles with standard (24 bit) addresses. 



can generate cycles with extended (32 bit) addresses 
can accept cycles with extended (32 bit) addresses, 
can monitor cycles with extended (32 bit) addresses. 
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Iii^l^MfJI" JTk^^T*^ !!] ^^^r®^^ ^°^^''^^ (AM) code along with each address to 
tell SLAVES whether the address is short, standard, or extended. 

Short_^ addresses are generated by A16 MASTERS, and accepted by A16 SLAVES 

af^A^wlo^ addresses are generated by A24 MASTERS, and accepted by A24 
A32 SLAVES^*^" addresses are generated by A32 MASTERS, and accepted by 

i.^Awtfi'^''®!^'"-? '^ intended primarily for addressing I/O devices. It allows A16 
fir? .• ^ .^fu^^^f;^ ^'^^ '®^® '°9''^' ^'"^® ^^^y ^° "o^ have to decode as many 
address Imes. While I/O boards can be designed to decode standard addresses and 
extended addresses, short addressing usually makes this unnecessary. 

Standard and extended addressing modes are intended primarily for addressina 
rnemory although there is no rule against designing I/O boards that also respond to 
these addressing modes. Standard and Extended addressing modes allow much 
larger addressing ranges. 

RULE 2.9: 

SLAVE boards MUST decode all of the address modifier lines. 

OBSERVATION 2.14: 

RULE 2.9 allows a SLAVE to differentiate short addresses, standard addresses, and 
extended addresses. 

OBSERVATION 2.15: 

In addition to the three modes of addressing described here, there is a fourth mode 
which IS used on interrupt acknowledge cycles (see chapter 4). These interrupt 
acknowledge cycles can be distinguished from data transfer cycles by the fact the the 
JACK* signal line is low instead of high. 

RULE 2.10: 

Whenever a MASTER broadcasts an address over the address bus, it MUST ensure 
that JACK* is high. 

PERMISSION 2.7: 

A MASTER MAY either drive lACK* high during the address broadcast or it MAY 
leave JACK* undriven. (The bus terminators will then hold it high.) 

RULE 2.11: 

SLAVES MUST NOT respond to DTB cycles when JACK* is low. 

RECOMMENDATION 2.2: 

Since many systems will include a mixture of A16, A24. and A32 SLAVES include 
A16 and A24 capability on 32-bit CPU cards in addition to the A32 capability and 
include A1 6 capability on CPU cards with A24 capability. 
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2.3.6 Basic Data Transfer Capabilities 



There are four basic data transfer capabilities associated witli the DTB: D08(EO) (Even 
and Odd byte), D08(O) (Odd byte only), D16, and D32. These capabilities allow 
flexibility when interfacing different types of processors and peripherals to the bus. 

Eight-bit processors can be interfaced to the bus as D08(EO) MASTERS. Sixteen-bit 
processors can be interfaced to the bus as D16 MASTERS. The D16 SLAVE module 
is useful for interfacing 16 bit memory devices or 16 bit I/O SLAVES to the DTB. 

Many existing peripheral chips have registers that are only 8 bits wide. While these 
chips often have several of these registers, they cannot provide the contents of two 
registers simultaneously when a D16 MASTER attempts to access two adjacent 
locations with a double byte read cycle. These 8-bit peripheral ICs can be interfaced 
to the DTB as a D08(O) SLAVE. D08(O) SLAVES provide only BYTE(1) or BYTE(3) 
locations and respond only to single byte accesses. (Since single byte accesses to 
these odd byte locations always take place over D00-D07, this simplifies the D08(O) 
SLAVE'S interface logic.) 

RECOIWIUIENDATION 2.3: 

Since most 16-bit microprocessors can also access memory 8 bits at a time, include 
D08(EO) MASTER capability on 16-bit CPU boards in addition to the D16 capability. In 
addition to allowing 8 bit data transfers to and from memory, this also allows them to 
access D08(O) SLAVES. 

RECOiyiMENDATION 2.4: 

Since most 32-bit microprocessors can also transfer data to and from memory 8 and 
16 bits at a time, include D08(EO) and D16 capability on 32-bit CPU boards in addition 
to D32 capability. The D08(EO) capability not only allows 8-bit data transfers to and 
from memory, but it also allows the MASTER to access D08(O) SLAVES. 

OBSERVATION 2.16: 

It might seem logical to define "even byte only" SLAVES which respond to the even 
byte memory locations adjacent to the D08(O) SLAVES. But, this cannot be done 
because there is only one data transfer acknowledge line. If a MASTER were to select 
both an even byte and an odd byte location simultaneously, by doing a double byte 
transfer, both SLAVES would drive the same data acknowledge (DTACK*) line and 
the MASTER would not know whether both boards had acknowledged the access. 

RECOMIWENDATION 2.5: 

Since many systems will include MASTERS with various data transfer capabilities, 
include D08(EO) and D16 capability on 32-bit SLAVE (memory) boards in addition to 
the D32 capability, and include D08(EO) capability on 16-bit SLAVE boards in 
addition to the D16 capability. 

OBSERVATION 2.17: ^ ^ .. 

Since D08(O) SLAVES respond only to odd byte addresses, they cannot provide 
contiguous memory. D08(O) SLAVES are useful only for I/O, status, or control 
registers, while D08(EO), D16 and D32 SLAVES are also useful for memory. 
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^^^'tr"^° s^°ws the various mnemonics used to describe the basic data transfer 
mJ?mix!^do ^"^ ^°^ ^^^^ '^ "^®^ ^° describe MASTERS. SLAVES, and LOCATION 



Table 2-10. Mnemonics That Specify Basic Data Transfer Capabilities 



The 


When 




Following 
Mnemonic 


Applied 
to a 


Means that it 


D08(EO) 


MASTER 


can generate the following cycles: 




SLAVE 


can accept the following cycles: 




LOCATION 
MONITOR 


can monitor the following cycles: 

Single byte read cycles: 
BYIb(0)READ 
BYIh(1)READ 
BYIb(2)READ 
BYTE(3) READ 

Single byte write cycles: 
BYTE(O) WRITE 
BY lh{1) WRITE 
BY lh(2) WRITE 
BY lh(3) WRITE 


D08(O) 


SLAVE 


can accept the following cycles: 

Single byte read cycles: 
BYTE(1)READ 
BYTE(3) READ 






Single byte write cycles: 
BY lh(1) WRITE 
BY lt(3) WRITE 
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Table 2-10. Mnemonics That Specify Basic Data Transfer Capabilities (cont'd) 



The 
Following 
Mnemonic 


When 
Applied 
to a 


Means that it 


D16 


MASTER 


can generate the following cycles: 




SLAVE 


can accept the following cycles: 




LOCATION 
MONITOR 


can monitor the following cycles: 

Double byte read cycles: 
BYTE(0-1)READ 
BY 1 h(2-3) READ 

Double byte write cycles: 
BY lt(0-1) WRITE 
BY lb(2-3) WRITE 


D32 


MASTER 


can generate the following cycles: 




SLAVE 


can accept the following cycles: 




LOCATION 
MONITOR 


can monitor the following cycles: 

Quad byte read cycle: 
BYTE(0-3) READ 

Quad byte write cycle: 
BYTE{0-3) WRITE 



B 



Note: (EO) is Even and Odd; (O) is Odd only. 



2.3.7 Block Transfer Capabilities 

MASTERS often access several memory locations in ascending order. When this is 
the case, block transfer cycles are very useful. They allow the MASTER to provide a 
single address, and then access data in that location and those at higher addresses, 
without providing additional addresses. 

When a MASTER initiates a block transfer cycle, the responding SLAVE latches the 
address into an on-board address counter. The MASTER, upon completing the first 
data transfer, (i.e. driving data strobes high) does not allow the address strobe to go 
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high. Instead, it repeatedly drives the data strobe(s) low in response to data transfer 
acknowledgnnents from the SLAVE, and transfers data to or from sequential memory 
locations in ascending order. 

To access the next location(s). the SLAVE increments an on-board counter that 
generates the address for each transition of the data strobe(s). 

OBSERVATION 2.18: 

Block transfer cycles of indefinite length are not allowed, because this complicates the 
design of memory boards. Specifically, all block transfer SLAVES (the one that 
responds, as well as those that do not) would need to latch the initial address and then 
increment the address counter on each bus transfer. All SLAVES would then have to 
decode the incremented address to see if the block transfer has crossed a board 
boundary into their address range. While this is certainly possible, such address 
decoding typically limits access times of the SLAVE. To simplify the design of these 
SLAVES, and to permit faster access times, RULE 2.12 has been formulated. 

RULE 2.12: 

Block transfer cycles MUST NOT cross any 256 byte boundary. 

OBSERVATION 2.19: 

RULE 2.12 limits the maximum length of block transfers to 256 bytes. However, 
knowing that only A01 through A07 will change during the course of the block transfer 
simplifies the design of block transfer SLAVES. The upper address lines only have to 
be decoded once, at the beginning of the block transfer cycle, allowing much faster 
access times on all subsequent data transfers. 

OBSERVATION 2.20: 

In some cases it might be necessary to transfer a large block of data which crosses 
one or more 256-byte boundaries. In such a case, if the hardware on the board which 
does the block transfer is designed to recognize the arrival at a 256-byte boundary, it 
can momentarily drive AS* high and then initiate another block transfer without the 
intervention of system software. 

The block read cycle is very similar to a string of read cycles. Likewise, the block write 
cycle is very similar to a string of write cycles. The difference is that only the initial 
address is broadcast by the MASTER and the address strobe is held low during all of 
the data transfers. 

OBSERVATION 2.21: 

Control of the DTB cannot be transferred during block transfers because the address 
strobe is held low through all of the data transfers, and control of the DTB can only be 
transferred while the address strobe is high. 

Table 2-1 1 lists the various mnemonics used to describe block transfer capabilities 
and how each is used to describe MASTERS, SLAVES, and LOCATION MONITORS. 
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Tab 


le 2-1 1 . Mnemonics That Specify Block Transfer Capabilities 


The 


When 




Following 
Mnemonic 


Applied 
to a 


Means that it 


BLT 


D08(EO) MASTER 


can generate the following cycles: 




D08(EO) SLAVE 


can accept the following cycles: 




D08(EO) LOCATION 
MONITOR 


can monitor the following cycles: 

Block read cycles: 
SINGLE BYTE BLOCK READ 

Block write cycles: 
SINGLE BYTE BLOCK WRITE 




D16 MASTER 


can generate the following cycles: 




D1 6 SLAVE 


can accept the following cycles: 




DISLOCATION 
MONITOR 


can monitor the following cycles: 

Block read cycles: 
DOUBLE BY 1 b BLOCK READ 

Block write cycles: 
DOUBLE BY Ih BLOCK WRITE 




D32 MASTER 


can generate the following cycles: 




D32 SLAVE 


can accept the following cycles: 




D32 LOCATION 
MONITOR 


can monitor the following cycles: 

Block read cycles: 
QUAD BYTE BLOCK READ 

Block write cycles: 
QUAD BYTE BLOCK WRITE 



I 
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2.3.8 Read-Modify-Write Capability 

In multiprocessor systems which share resources such as memory and I/O, a method 
is needed to allocate these resources. One very important goal of this allocation 
algorithm is to ensure that a resource being used by one task cannot be used by 
another at the same time. The problem is best described by an example: 

Two processors in a distributed processing system share a common resource (e.g., a 
printer). Only one processor can use the resource at a time. The resource is allocated 
by a bit in memory - i.e., if the bit is set, the resource is busy; if it is cleared, the 
resource is available. To gain use of the resource, processor A reads the bit and tests 
it to determine whether it is cleared. If the bit is cleared, processor A sets the bit to lock 
out processor B. This operation takes two data transfers: a read to test the bit, and a 
write to set the bit. However, a difficulty might arise if the bus is given to processor B 
between these two transfers. Processor B might then also find the bit cleared and 
assume the resource is available. Both processors will then set the bit in the next 
available cycle and attempt to use the resource. 

This conflict is avoided by defining a read-modify-write cycle which prevents 
transferring control of the DTB between the read portion and the write portion of the 
cycle. This cycle is very similar to a read cycle immediately followed by a write cycle. 
The difference is that the address strobe is held low during both transfers. This 
ensures that, unlike a read cycle followed by a write cycle, control of the DTB cannot 
be transferred during a read-modify-write cycle, as this is only possible while the 
address strobe is high. 

Table 2-12 lists the various mnemonics used to describe read-modify-write capabilities 
and how each is used to describe MASTERS, SLAVES, and LOCATION MONITORS. 
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Table 2-12. Mnemonics That Specify Read-Modify-Write Capabilities 



The 
Following 
Mnemonic 



When 
Applied 
to a 



Means that it 



RMW D08(EO) MASTER 

D08(EO) SLAVE 

D08(EO) LOCATION 
MONITOR 



D08(O) SLAVE 



D1 6 MASTER 

D1 6 SLAVE 

DISLOCATION 
MONITOR 



D32 MASTER 

D32 SLAVE 

D32 LOCATION 
MONITOR 



can generate the following cycles: 

can accept the following cycles: 

can monitor the following cycles: 

Single byte read-modify-write cycles: 
BYTE(O) READ-MODIFY-WRITE 
BYTE(1) READ-MODIFY-WRITE 
BYTE{2) READ-MODIFY-WRITE 
BYTE(3) READ-MODIFY-WRITE 



can accept the following cycles: 

Single byte read-modify-write cycles: 
BYTE(1) READ-MODIFY-WRITE 
BYTE(3) READ-MODIFY-WRITE 



can generate the following cycles: 

can accept the following cycles: 

can monitor the following cycles: 

Double byte read-modify-write cycles: 
BYTE(0-1) READ-MODIFY-WRITE 
BYTE(2-3) READ-MODIFY-WRITE 



can generate the following cycles: 

can accept the following cycles: 

can monitor the following cycles: 

Quad byte read-modify-write cycles: 
BYTE(0-3) READ-MODIFY-WRITE 



B 
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2.3.9 Unaligned Transfer Capability 



I 



Some 32-bit microprocessors store and retrieve data in an unaligned fashion. For 
example, a 32-bit value might be stored in four different ways, as shown in Figure 2-6. 



Example Example Example Example 
A B C D 



4-byte group 
number 2 



4-byte group 
number 1 



BYTE(3) 
BYTE(2) 
BYTE(1) 
BYTE(O) 
BYTE(3) 
BYTE(2) 
BYTE(1) 
BYTE(O) 



Figure 2-6. Four Ways That 32 Bits Of Data Might Be Stored In Memory 

The MASTER can transfer the 32 bits of data using several different sequences of DTB 
cycles. For example, it can transfer the data one byte at a time, using four single byte 
data transfers. However, a MASTER can accomplish the transfer much quicker by 
using one of the cycle sequences shown in Table 2-1 3. 

OBSERVATION 2.22: 

The sequences shown in Table 2-13 would be typical of a MASTER that accesses the 
byte locations in ascending order. The VMEbus protocol does not require this. 

As shown in Table 2-13, each of these 32-bit transfers can be accomplished with a 
combination of single byte and double byte transfers. However, examples B and D 
require three bus cycles when done this way. Because of this, the DTB protocol also 
includes two triple byte transfer cycles. When used in combination with a single byte 
cycle, these triple byte cycles allow data to be stored as shown in examples B and D 
using only two bus cycles. 

Some 32-bit microprocessors also store and retrieve data 16 bits at a time, in an 
unaligned fashion, as shown in Figure 2-7. 
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Table 2-13 


. Transferring 32 Bits Of Data Using Multiple Byte Transfer Cycles 


Example 


Cycle sequences used to 
accomplish the transfer 


Data bus 
lines used 


Byte locations 

accessed 
(See Figure 2-6) 


A 


Quad byte transfer 


D00-D31 


Grp1,BYTE(0-3) 


B 


Single byte transfer 
Double byte transfer 
Single byte transfer 

or 
Triple byte transfer 
Single byte transfer 


D00-D07 
D00-D15 
D08-D15 

D00-D23 
D08-D15 


Grp1,BYTE(1) 

Grp1,BYTE(2-3) 

Grp2,BYIb(0) 

Grp1,BYTE(1-3) 
Grp 2, BYTE(O) 


C 


Double byte transfer 
Double byte transfer 


D00-D15 
D00-D15 


Grp1,BYTE(2-3) 
Grp2,BYTE(0-1) 


D 


Single byte transfer 
Double byte transfer 
Single byte transfer 

or 
Single byte transfer 
Triple byte transfer 


D00-D07 
D00-D15 
D08-D15 

D00-D07 
D08-D31 


Grp1,BYIh(3) 
Grp2, BYTE(0-1) 
Grp 2, BYTE(2) 

Grp1,BYTE(3) 
Grp 2, BYTE(0-2) 



B 



4-byte group 
number 2 



4-byte group 
number 1 



BYTE(3) 
BYTE(2) 
BYTE(1) 
BYTE(O) 
BYTE(3) 
BYTE{2) 
BYTE(1) 
BYTE(O) 



Example Example Example Example 
E F G H 



Figure 2-7. Four Ways That 16 Bits Of Data Might Be Stored In Memory 
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The MASTER can transfer the 16 bits of data using several different sequences of DTB 
cycles as listed in Table 2-14. 

OBSERVATION 2.23: 

The sequences listed in Table 2-14 would be typical of a MASTER that accesses the 
byte locations in ascending order. The VMEbus protocol does not require this. 

As shown in Figure 2-13, the 16-bit transfer in example F can be accomplished with 
two single byte transfers. However, this requires two bus cycles. Because of this, the 
DTB protocol also includes a double byte transfer cycle which allows data to be stored 
as shown in example F using only one bus cycle. 

OBSERVATION 2-24: 

Since unaligned transfers make use of all 32 data lines, only D32 MASTERS and 
SLAVES can do unaligned transfers. 

Table 2-15 lists how the unaligned transfer (DAT) mnemonic is used to describe 
MASTERS, SLAVES, and LOCATION MONITORS. 



Table 2-14. Transferring 16 Bits Of Data Using Multiple Byte Transfer Cycles 



Example 


Cycle sequences used to 
accomplish the transfer 


Data bus 
lines used 


Byte locations 
accessed 
(See Figure 2-7) 


E 


Double byte transfer 


D00-D15 


Grp1,BYIb(0-1) 


F 


Single byte transfer 
Single byte transfer 

or 
Double byte transfer 


D00-D07 
D08-D15 

D08-D23 


Grp1,BYTE(1) 
Grp1,BYIb(2) 

Grp1,BYTE(1-2) 


G 


Double byte transfer 


D00-D15 


Grp1,BYTE(2-3) 


H 


Single byte transfer 
Single byte transfer 


D00-D07 
D08-D15 


Grp1,BYTE(3) 
Grp2,BYIh(0) 
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Table 2-15. Mnemonic That Specifies Unaligned Transfer Capability 



The 
Following 
Mnemonic 


When 
Applied 
to a 


Means that it 


UAT 


D32 MASTER 


can generate the following cycles: 




D32 SLAVE 


can accept the following cycles: 




D32 LOCATION 
MONITOR 


can monitor the following cycles: 

Triple byte read cycles: 
BYTE{0-2) READ 
BYIh(1-3)READ 

Triple byte write cycles: 
BY lh(0-2) WRITE 
BYIh(1-3)WRITE 

Double byte read cycle: 
BYTE(1-2)READ 

Double byte write cycle: 
BYTE(1-2)WRITE 



I 



2.3.10 ADDRESS-ONLY Capability 

The ADDRESS-ONLY cycle is the only cycle on the DTB that is not used to transfer 
data. It begins as a typical DTB cycle, with the address/address modifier code, lAGK* 
and LWORD* lines becoming valid and the address strobe falling after a set-up time. 
However, the data strobes are never driven low. After holding the various lines 
strobed by the address strobe stable for a prescribed minimum period, the MASTER 
finishes the cycle without waiting for DTACK* or BERR* to go low. (The ADDRESS- 
ONLY cycle is also the only type of DTB cycle that does not require a response in 
order to complete.) 

Table 2-16 lists how the ADDRESS-ONLY mnemonic (ADO) is used to describe 
MASTERS and SLAVES. 

OBSERVATION 2.25: 

ADDRESS-ONLY cycles can be used to enhance board performance by allowing a 
CPU board to broadcast an address before it has determined whether or not that 
address selects a SLAVE on the VMEbus. Broadcasting the address in this fashion 
allow VMEbus SLAVES to decode the address concurrently with the CPU board. 
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RECOMMENDATION 2.6: 

Since MASTERS might generate ADDRESS-ONLY cycles, design SLAVES to include 
ADO capability. 



Table 2-16. Mnemonic That Specifies ADDRESS-ONLY Capability 



The 
Following 
Mnemonic 



ADO 



When 
Applied 
to a 



Means that it 



MASTER can generate ADDRESS-ONLY cycles 

SLAVE can tolerate ADDRESS-ONLY cycles without 

loss or alteration of stored data. 



2-3-11 Interaction Between DTB Functional Modules 

Data transfers take place between MASTERS and SLAVES. The MASTER is the 
module controlling the transfer. The SLAVE which recognizes the address as its own 
is the responding SLAVE, and all other SLAVES are non-responding SLAVES. 

After initiating a data transfer cycle, the MASTER waits for a response from the 
responding SLAVE. When the MASTER detects the response from the SLAVE it 
drives the data strobes and address strobe high, terminating the cycle. The SLAVE 
responds by releasing its response line. 

OBSERVATION 2-26: 

Although the address and data timing are largely independent, there are two 
exceptions. First, the MASTER waits until it has driven AS* low before driving either of 
the data strobes low. Second, the SLAVE acknowledges both the address strobe and 
the data strobes with either DTACK* or BERR*. 

RULE 2.13: 

IF a SLAVE responds to a data transfer cycle, 

THEN it MUST either drive DTACK* low or it MUST drive BERR* low, but not both. 

OBSERVATION 2.27: 

Because of possible bus skew due to different loading of the address strobe and the 
data strobes, the falling edge of the data strobes might be detected by the SLAVE 
slightly before the address strobe falling edge. 

OBSERVATION 2.28: 

The WRITE* line is high/low to identify a read/write cycle before the first data strobe is 
driven low, and remains stable until both data strobes are high. 
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RULE 2.14: 

Before driving the data bus, the MASTER MUST ensure that the previous responding 
SLAVE has stopped driving the data bus. It does so by verifying that DTACK* and 
BERR* are both high before it drives the data strobe(s) to low on any cycle, and before 
it drives any of the data lines during a write cycle. 

RULE 2.15: 

At the end of a read cycle the responding SLAVE MUST release the data bus before 
allowing DTACK* to go high. 

RULE 2.16: 

When the MASTER reads data from the SLAVE, the SLAVE MUST maintain valid 
data on the data bus until the MASTER returns the first data strobe to high. 

SUGGESTION 2.3: 

For optimum performance, design MASTERS so that they drive the data strobes high 
as soon as possible after DTACK* or BERR* goes low. Also, design SLAVES so that 
they release the data bus and DTACK* as soon as possible after detecting the data 
strobes high. This allows the maximum data transfer rate on the bus. 

OBSERVATION 2.29: 

Addressing information on the bus might change soon after a module drives DTACK* 
or BERR* low, and before the MASTER drives the data strobes high. 

A third type of module, called the LOCATION MONITOR, monitors the data transfer and 
generates either or both of two on-board signals whenever an access is done to a byte 
location that it monitors. If the access is a write cycle, then the on-board WRITE signal 
is generated. If the access is a read cycle, then the on-board READ signal is 
generated. If a read-modify-write cycle is performed, then both on-board signals are 
generated. 

If the cycle takes too long, a fourth module, called a BUS TIMER intervenes by driving 
BERR* low, this completes the data transfer handshake, and allows the bus to resume 
operation. 

RULE 2.17: 

There is a strict interlock between the rising and falling edges of the data strobes and 
DTACK*/BERR*. Once a MASTER has driven its data strobe(s) low it MUST NOT 
drive its data strobe(s) high and finish a transfer without first receiving a data transfer 
acknowledge or a bus error response. 

OBSERVATION 2.30: . ,^ 

A board containing a processor, which needs to direct data transfers between itself 
and other VMEbus boards, would contain a MASTER module. If the same board also 
contained memory accessible from the VMEbus, it would also contain a SLAVE 
module. A floating point processor or intelligent peripheral controller might receive 
commands through a SLAVE interface from a general purpose processor board. It 
then might act as a MASTER to access global VMEbus memory to execute the 
command it has been given. 
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2.4 TYPICAL OPERATION 



MASTERS initiate data transfers over the DTB. The addressed SLAVE then 
acknowledges the transfer. After receiving the data transfer acknowledge, the 

a MASTER terminates the data transfer cycle. The asynchronous nature of the DTB 
allows the SLAVE to control the time taken for the transfer. 
Before doing any data transfers, a MASTER has to be granted exclusive control of the 
DTB. This ensures that multiple MASTERS will not try to use the DTB at the same 
time. The MASTER gains control of the DTB using the modules and signal lines of the 
Arbitration Bus. (Section 2.5 explains this further) The following discussion presumes 
that the MASTER has already been granted and has assumed control of the DTB. 

2.4.1 Typical Data Transfer Cycles 

Figure 2-8 shows a typical single byte read cycle. To start the transfer, the MASTER 
drives the addressing lines with the desired address and address modifier code 
Since this example is a BYTE(1) READ CYCLE, the MASTER drives LWORD* high 
and A01 low. Since it is not doing an interrupt acknowledge cycle, it does not drive 
lACK* low. The MASTER then waits for a specified set-up time before driving AS* low, 
to allow the address lines and the address modifier lines to stabilize before the 
SLAVES sample them. 

Each SLAVE determines whether it should respond by examining the levels on the 
address lines, the address modifier lines, and JACK*. While this is happening, the 
MASTER drives WRITE* high to indicate a read operation. The MASTER then verifies 
that DTACK* and BERR* are high to ensure that the SLAVE from the previous cycle is 
no longer driving the data bus. If this is the case, the MASTER then drives DSO* low 
while keeping DSr high. 

The responding SLAVE then determines which 4-byte group and which byte of that 
group is to be accessed, and starts the transfer. After it has retrieved the data from its 
internal storage and placed it on data bus lines D00-D07, the SLAVE signals the 
MASTER by driving DTACK* low. The SLAVE then holds DTACK* low and maintains 
the data valid for as long as the MASTER holds DSO* low. 

When the MASTER receives DTACK* driven to low, it captures the data on D00-D07, 
releases the address lines and drives DSO* and AS* to high. The SLAVE responds by 
releasing D00-D07 and releasing DTACK* to high. 

OBSERVATION 2.31: 

The MASTER in Figure 2-8 releases all of the DTB lines at the end of the data transfer. 
This is not required unless the MASTER'S REQUESTER released BBSY* during the 
data transfer as described in Section 2.5. 

The cycle flow for double byte and quad byte data transfer cycles are very similar to 
the single byte cycle. Flow diagrams for these cycles are shown in Figures 2-9 and 2- 
10. 
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MASTER 

I 
ADDRESS THE SLAVE 

Present address 
Present address modifier 
Drive LWORD* higii 
Drive lACK* high 
Drive AS* to low 



SPECIFY DATA DIRECTION 
Drive WRITE* high 



SPECIFY DATA WIDTH 

Wait until DTACK* high and 
BERR* high (indicates that 
previous SLAVE is no longer 
driving data bus) 

Drive DSO* to low and DS1* to high 



SLAVE 



I 



PROCESS ADDRESS 

Receive address 

Receive address modifier 

Receive LWORD* high 

Receive lACK* high 

Receive AS* low 

If address is valid for this SLAVE 

Then select on-board device 



FETCH 



DATA 



Receive WRITE* high 

Read data from selected device 

Receive DSr high 

Receive DSO* low 

Present data on lines D00-D07 



(Continued on sheet 2) 



Figure 2-8. An Example Of A Single Byte Read Cycle (Sheet 1 Of 2) 



55 



DATA TRANSFER BUS 



a 



ACQUIRE DATA 

Receive data on lines D00-D07 
Receive DTACK* low 



TERMINATE CYCLE 

If last cycle then 

Release address lines 

Release address modifier lines 

Release LWORD* 

Release lACK* 
Endif 

Drive DSO* to high 
Drive AS* to high 



END TERMINATION 

If last cycle then 
Release DSO* and DS1* 
P9I9Q3Q AS* 

Else go to ADDRESS THE SLAVE 
Endif 



RESPOND TO MASTER 
Drive DTACK* to low 



END RESPONSE TO MASTER 



Receive AS* and DSO* high 
Release D00-D07 



ACKNOWLEDGE TERMINATION 
Release DTACK* 



Figure 2-8. An Example Of A Single Byte Read Cycle (Sheet 2 Of 2) 
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MASTER 

I 
ADDRESS THE SLAVE 

Present address 
Present address modifier 
Drive LWORD* high 
Drive JACK* high 
Drive AS* to low 



SLAVE 



SPECIFY DATA DIRECTION 
Drive WRITE* low 



SPECIFY DATA WIDTH 

Wait until DTACK* high and 
BERR* high (indicates that 
previous SLAVE is no longer 
driving data bus) 
Place data on D00-D15 
Drive DSO* and DS1* to low 
L 



E 



PROCESS ADDRESS 

Receive address 

Receive address modifier 

Receive LWORD* high 

Receive lACK* high 

Receive AS* low 

If address is valid for this SLAVE then 

select on-board device 



STORE DATA 

Receive WRITE* low 

Receive DSr low 

Receive DSO* low 

Capture data from lines D00-D15 

Write data into selected device 



RESPOND TO MASTER 
Drive DTACK* to low 



(Continued on sheet 2) 



Figure 2-9. An Example Of A Double Byte Write Cycle (Sheet 1 Of 2) 
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TERMINATE CYCLE 

I 
Receive DTACK* low 
If last cycle then 

Release address lines 

Release address modifier lines 

Release data lines 

Release LWORD* 

Release lACK* 
Endif 

Drive DSO* and DS1* to high 
Drive AS* to high 



END TERMINATION 

I 
If last cycle then 

Release DSO* and DS1* 

Release AS* 
Else go to ADDRESS THE SLAVE 
Endif 



ACKNOWLEDGE TERMINATION 

Receive AS*, DSO*, and DS1* high 
Release DTACK* 



Figure 2-9. An Example Of A Double Byte Write Cycle (Sheet 2 Of 2) 
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MASTER 

I 
ADDRESS THE SLAVE 

Present address 
Present address modifier 
Drive LWORD* low 
Drive lACK* high 
Drive AS* to low 



SLAVE 



SPECIFY DATA DIRECTION 
Drive WRITE* low 



SPECIFY DATA WIDTH 

I 
Wait until DTACK* high and 
BERR* high (indicates that 
previous SLAVE is no longer 
driving data bus) 
Place data on D00-D31 
Drive DSO* and DS1* to low 



I 



PROCESS ADDRESS 

Receive address 

Receive address modifier 

Receive LWORD* low 

Receive lACK* high 

Receive AS* low 

If address is valid for this SLAVE 

Then select on-board device 



STORE DATA 

Receive WRITE* low 
Receive DSr low 
Receive DSO* low 
Latch data from lines D00-D31 
Write data into selected device 



RESPOND TO MASTER 
Drive DTACK* to low 



(Continued on sheet 2) 



Figure 2-10. An Example Of A Quad Byte Write Cycle (Sheet 1 Of 2) 
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1 



TERMINATE CYCLE 

Receive DTACK* low 
If last cycle then 

Release address lines 

Release address modifier lines 

Release data lines 

Release LWORD* 

Release lACK* 
Endif 

Drive DSO* and DS1* to high 
Drive AS* to high 



} 



END TERMINATION ACKNOWLEDGE TERMINATION 

If last cycle then Receive AS*, DSO*, and DS1 * high 

Release DSO* and DS1* Release DTACK* 

Release AS* 

Else go to ADDRESS THE SLAVE 

Endif 



Figure 2-1 0. An Example Of A Quad Byte Write Cycle (Sheet 2 Of 2) 

2,4.2 Address Pipelining 

The VMEbus strobes the address and data with separate strobe signals. This allows a 
MASTER to broadcast the address for the next cycle while the data transfer for the 
previous cycle is still in progress. This is called "address pipelining". 

PERIVIISSION 2.8: 

As soon as a SLAVE drives DTACK* or BERR* low, the MASTER MAY change the 
address and, after driving AS* high for a minimum time, drive AS* low again. 

For example, when a SLAVE drives DTACK* low on a read cycle, the MASTER can 
place a new address on the address bus while it is reading the data from the bus. This 
amounts to an overlapping of one cycle with the next one, and permits greater speeds 
on the VMEbus. 

RULE 2.18: 

Since address pipelining can occur, SLAVES MUST NOT be designed on the 
assumption that they will never encounter pipelined cycles. 
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OBSERVATION 2.32: 

The responding SLAVE might recognize its address and respond very quickly on the 
DTACK* or BERR* lines. Since the MASTER is permitted to remove the address after 



the responding SLAVE drives DTACK* or BERR* low, non-respondmg SLAVES might 

not be able to decode the addressing information before the MASTER removes It from mmm 

I 



the bus 



SUGGESTION 2.4: 

Design SLAVES to capture the addressing information on the failing edge of AS . 

OBSERVATION 2.33: , . 

Because a MASTER might broadcast a new address while a previous cycle is 
finishing, the designer needs to ensure that the assertion of the second address strobe 
does not invalidate the first address if it is still needed by on-board logic to maintain 
the data on the bus. 

PERMISSION 2.9: 

MASTERS MAY be designed without the ability for address pipelining, (e.g. They 
MAY wait until the responding SLAVE releases DTACK* or BERR* before driving AS* 
low for the next cycle.) 

OBSERVATION 2.34: ' ^. ^ ^ 

A MASTER might drive AS* low for a new cycle before it drives data strobes high from 
the previous cycle. Because of this, there might be a period when the address strobe 
for the new cycle, as well as at least one data strobe from the previous cycle coincide 
during the cycle overlap. 

SUGGESTION 2.5: ^ ^ ' ^, ,k 

To assure reliable operation, design SLAVES to initiate data transfers to and from the 
bus on the falling edge of the data strobes, instead of a simultaneous low level on 
the address strobe and data strobes. 

2.5 DATA TRANSFER BUS ACQUISITION 

RULE 2.19: .^, . * 

Before transferring any data on the DTB, a MASTER MUST get permission to use it. 

Several MASTERS might want to use the DTB at the same time. The process which 
determines which MASTER can use the DTB is called arbitration and is discussed in 
Chapter 3. Because arbitration is closely tied to the operation of the DTB, it is bnefly 
described here. 

Figure 2-11 provides two examples that show possible sequences when a MASTER 
(called MASTER A) finishes using the DTB and allows arbitration to take place. 

In Example 1, MASTER A, partway into its last transfer, indicates that it no longer 
needs the DTB. It does this by having its REQUESTER release the bus busy (BBSY ) 
signal line. Since MASTER A gives this early notice that the DTB will soon be 
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nomnlSfn o®wf.Ae™ J^. '^°"® ''"""9 '*^ '^^* data transfer. The arbitration is 
completed and IVIASTER B is granted permission to use the DTB before MASTER A 

MA^-Sl^ '*•!. '^y^'®' ^^^ '* *^'*s ""*'• MASTER A releases AS*. (This assures that 
MASTER B will not start driving the DTB before MASTER A has finished with its last 

1ci3t3 trsnsTGr.) 
In Example 2 MASTER A waits until after its last transfer (i.e.. after AS* is released) 
ul^rJnlt^'1^ ^^^^; JV^l^ ^^^® ^^® ^"^^ 's 'd'® ^^^"e the arbitration is done! 
DTB imSediatef ®" ^"^' ^'"°® '^^* '^ ^'''^^^y '^'9'^' '* begins using the 

RULE 2.20: 

Once a MASTER'S REQUESTER releases BBSY*to high, the MASTER MUST NOT 

p'i!:nMnlxco°"' ^'S*^ *° '°'' ('•®- '* """S"^ NOT begin a new cycle) until its 
REQUESTER receives a new bus grant. 

2.6 DTB TIMING RULES AND OBSERVATIONS 

This section describes the timing RULES and OBSERVATIONS that govern the 
behavior of MASTERS and SLAVES. This timing information is in the form of Figures 
and Tables: *" 

^®!?'.®^?r]Il.!i?K*?.fJi'??'"9 '^^^^^ ^"^ ^''^'"Q diagrams that specify MASTER, SLAVE, 
and LOCATION MONITOR operation. 

Table 2-18 defines the various mnemonics that are used in this section. 

Tables 2-19 through 2-21 specify the use of the DTB signals. 

Tables 2-22 through 2-27 specify the timing parameters of the DTB. (The 
reference numbers used in Tables 2-24 through 2-27 correspond to the timina 
parameter numbers in Tables 2-22 and 2-23.) ^ a 

Figures 2-12 through 2-15 specify the timing RULES and OBSERVATIONS durinq 
address broadcasting time. ^ 

Figures 2-16 through 2-21 specify the timing RULES and OBSERVATIONS for 
MASTERS, SLAVES, and LOCATION MONITORS during data transfer time. 

ri?J^t®® ^'^^ through 2-24 specify the timing RULES and OBSERVATIONS for 
MASTERS and SLAVES between DTB cycles. 

Figure 2-25 is the timing diagram for MASTER, SLAVE, and BUS TIMER durina a 
timed-out cycle. ^ 

Figure 2-26 shows the timing during the mastership transfer of the DTB. 
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MASTER A USING DTB 

I ^ 



MASTER B USING DTB 



WRITE 



READ 



READ 



WRITE 



AS* 



BBSY* 



f\_I\-JX_J\—f\- 



I 



(MASTER A) 



BGXIN* TO MASTER B 




(MASTER B) 



ARBITRATION TIME 



Example 1 -Arbitration DURING The Last Data Transfer 



MASTER A USING DTB 



WRITE READ 



MASTER B USING DTB 



"1 \ 



READ 



WRITE 



AS* 



BBSY* 



/V_J\-f 



(MASTER A) 



BGXIN* TO MASTER B 




ARBITRATION TIME 



Example 2 -- Arbitration AFTER The Last Data Transfer 
Figure 2-1 1 . Data Transfer Bus MASTER Excliange Sequence 
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^ZnnnZ\}?."'^V^^ Specified timing RULES, board designers need to tal<e into 
S VMPhirr* ^ase propagation delays of the bus drivers and receivers used on 
n«l JIh^ ^°f''^f- ^^^ Prapagation delay of the drivers depends on their output 
loads and manufacturers specifications do not always give enough information to 

I calculate the propagation delays under various loads. To help the VMEbus board 
designer, some suggestions are offered in Chapter 6. 
tTmt™^h"J'^T'?'^^ ^P®^'^ **^® ^'"^'"9 °^ incoming lines signal transitions. These 
times can be relied upon as long as the backplane loading RULES in Chapter 6 are 
not violated The RULES for the bus terminator in Chapter 6 guarantee that the timfnq 
parameters for signal lines that are released after they have been driven, are met 

Typically for each timing RULE there is a corresponding OBSERVATION. However 
L^ftS^I, n c 's guaranteed in the OBSERVATION might differ from the time specified 
k/ac?cd • °'' ^j^^'^P'®' a careful inspection of the timing diagrams shows that the 
ih« oT Auc .''®^"'r®d *o Pi'ov'de 35 nanoseconds of address and data set-up time, but 
the SLAVE is only guaranteed 10 nanoseconds. This is because the address and 

th^n!.nhl T^ uV°^ ^''^fy® ^'''® ^° ^"^® ^^^ backplane's signal lines completely 
through the threshold region from low to high until the transition propagates to the end 
ctrlh® H^'^P'^"® f"d is reflected back. The falling edge of the address and data 
strobes, however, typically cross the 0.8-volt threshold without waiting for a reflection 

JropaglSn?imIs''^ *''"® ^* ^^^ ^""^^^ '^ ^^^ IVIASTER'S set-up time less two bus 

A special notation has been used to describe the data strobe timing. The two data 
strobes (DSO* and DSI*) will not always make their transitions simultaneously For 
purposes of these timing diagrams. DSA* represents the first data strobe to make its 
ISL°" («"]ether that is^ DSO* or DSr). The broken line shown while the d^l 
strobes are stab e is to indicate that the first data strobe to make a falling transition 
might not be the first to make its rising transition ~ i.e.. DSA* can represent DSO* on its 
failing edge and DS1* on its rising edge. 
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Table 2-17. Timing Diagrams That Define MASTER, SLAVE, And LOCATION 
MONITOR Operation (See Table 2-22 for timing values) 



Mnemonic 


Type of cycles 


Address 
Broadcast 
Timing Diag 
Figure(s) 


Data 
Transfer 
Timing Diag 
Figure 


ADO 


ADDRESS-ONLY 


2-12 


N/A 


D08(EO) 


Single even byte transfers 








BYTE(0)READ 
BYIb(2)READ 


2-12 & 2-13 
2-12 & 2-13 


2-16 
2-16 




BYTE(O) WRITE 
BYTE(2) WRITE 


2-12 & 2-13 
2-12&2-13 


2-18 
2-18 


D08(EO) 


Single odd byte transfers 






or 


BYTE(1)READ 
BYIb(3)READ 


2-12 & 2-13 
2-12 & 2-13 


2-16 
2-16 


D08(O) 


BYTE(1) WRITE 
BYTE(3) WRITE 


2-12 & 2-13 
2-12 & 2-1 3 


2-18 
2-18 


D16 


Double byte transfers 








BYTE(0-1)READ 
BYTE(2-3) READ 


2-12 & 2-13 
2-12 & 2-13 


2-17 
2-17 




BYTE{0-1) WRITE 
BYTE(2-3) WRITE 


2-12 & -2-1 3 
2-12 & 2-13 


2-19 
2-19 


D32 


Quad byte transfers 








BYTE(0-3) READ 


2-12 & 2-13 


2-17 




BYTE(0-3) WRITE 


2-12 & 2-13 


2-19 


D08(EO):BLT 


Single byte block transfers 








SINGLE BYTE BLOCK READ 


2-12 & 214 


2-16 




SINGLE BYTE BLOCK WRITE 


2-12 & 214 


2-18 



I 



65 



DATA TRANSFER BUS 



Table 2-17. Timing Diagrams That Define MASTER, Si-AVE, And LOCATION 
MONITOR Operation (See Table 2-22 for timing values) (cont'd) 



I 



Mnemonic 



Type of cycles 



Address Data 

Broadcast Transfer 
Timing Diag Timing Diag 
Figure(s) Figure 



D1 6:BLT Double byte block transfers 

DOUBLE BYTE BLOCK READ 
DOUBLE BYTE BLOCK WRITE 



D1 6:RMW Double byte RMW transfers 

BYTE(0-1) READ-MODIFY-WRITE 
BYTE(2-3) READ-MODIFY-WRITE 



2-12 & 2-15 
2-12 & 2-15 



D32:RMW Quad byte RMW transfers 

BYTE(0-3) READ-MODIFY-WRITE 2-12 & 2-15 



D32:UAT 



Unaligned transfers 

BYTE(0-2) READ 
BYTE(1-3) READ 
BYTE(1-2)READ 

BYTE(0-2) WRITE 
BYTE(1-3)WRITE 
BYTE(1-2)WRITE 



2-12 & 2-13 
2-12 & 2-13 
2-12 & 2-13 

2-12 & 2-13 
2-12 & 2-13 
2-12 & 2-13 



2-12 & 2-14 2-17 
2-12 & 2-14 2-19 



D32:BLT Quad byte block transfers 

QUAD BYTE BLOCK READ 2-12 & 2-14 2-17 

QUAD BYTE BLOCK WRITE 2-12 & 2-14 2-19 



D08(EO):RMW Single byte RMW transfers ~ 

BYTE(O) READ-MODIFY-WRITE 2-12 & 2-15 2-20 

BYTE(1 ) READ-MODIFY-WRITE 2-1 2 & 2-1 5 2-20 

BYTE(2) READ-MODIFY-WRITE 2-12 & 2-15 2-20 

BYTE(3) READ-MODIFY-WRITE 2-12 & 2-15 2-20 



2-21 
2-21 



2-21 



2-16 
2-16 
2-17 

2-18 
2-18 
2-19 



66 



DATA TRANSFER BUS 



Tables 2-19, 2-20, and 2-21 show how the various signal lines of the DTB are used to 
broadcast addresses and to transfer data. These Tables are referenced by the various 
timing diagrams that follow. In order to keep these Tables compact, mnemonics are 
used to describe when and how the various lines are driven. These mnemonics are 
defined in Table 2-18. 

Table 2-18. Definitions Of Mnemonics Used in Tables 2-19, 2-20, And 2-21 



I 



Mnemonic Description 



Comments 



DVBM DRIVEN VALID RULE 2.21: 

BY MASTER The MASTER iUIUST drive DVBM lines to a valid level 



DLBM DRIVEN LOW RULE 2.22: 

BY MASTER The MASTER MUST drive DLBM lines to a low level. 



DHBM DRIVEN HIGH RULE 2.23: _ . ^ , , 

BY MASTER The MASTER MUST drive DHBM lines to a high level 



dhbm? DRIVEN HIGH PERMISSION 2.10: 

BY MASTER? The MASTER MAY drive dhbm? lines high. 

RULE 2.24: 

The MASTER MUST NOT drive dhbm? lines low. 



dxbm? DRIVEN BY PERMISSI0N2.il: 

MASTER? The MASTER MAY drive dxbm? lines, or it MAY 

leave these lines undriven. (When dxbm? lines 
are driven, they carry no valid information.) 
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Table 2-18. Definitions Of Mnemonics Used In Tables 2-19, 2-20, And 2-21 (cont'd) 



I 



Mnemonic Description 



DVBS DRIVEN VALID 
BY SLAVE 



dxbs? 



DRIVEN BY 
SLAVE? 



DVBB DRIVEN VALID 
BY BOTH SLAVE 
AND MASTER 



dxbb? DRIVEN BY BOTH 
SLAVE AND 
MASTER? 



Comments 



RULE 2.25: 

The SLAVE MUST drive DVBS lines to a valid 

level. 



PERMISSION 2.12: 

The SLAVE MAY drive dxbs? lines, or it MAY 

leave these lines undriven. 

(When dxbs? lines are driven, they carry no 

valid information.) 



RULE 2.26: 

During the "read" portion of a readmodify 

write cycle, the SLAVE MUST drive DVBB lines 

with valid data. During the "write" portion 

of a read-modify-write cycle, the MASTER 

MUST drive DVBB lines with valid data. 



PERMISSION 2.13: 

During the "read" portion of a readmodify 

write cycle, the SLAVE MAY drive dxbb? 

lines, or it MAY leave them undriven. During 

the "write" portion of a read-modify-write 

cycle, the MASTER MAY drive dxbb? lines, or 

it MAY leave them undriven. 

(When dxbb? lines are driven, they carry no 

valid information.) 
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Table 2-19. Use Of Addressing Lines To Select A 4-Byte Group 



Mnemonic 


Addressing 
mode 


A02-A15 
See 
Note 


A16-A23 


A24-A31 


JACK* 


A16 


SHORT 


DVBM 


dxbm? 


dxbm? 


dhbm? 


A24 


STANDARD 


DVBM 


DVBM 


dxbm? 


dhbm? 


A32 


EXTENDED 


DVBM 


DVBM 


DVBM 


dhbm? 



B 



Note: A01 is used in conjunction with LWORD* and tiie two data strobes to select 
which of the four bytes within the 4-byte group is accessed. (See Table 2-20). 



Table 2-20. Use Of The DSr, DSO*, A01 , And LWORD* Lines To Select 
The Byte(s) Within A 4-Byte Group 



Mnemonic Type of cycles 



ADO ADDRESS-ONLY 



D08(EO) Single even byte transfers 

BYTE(O) READ or WRITE 
BYTE(2) READ or WRITE 



D08(EO) Single odd byte transfers 

or 
D08(O) BYTE(1 ) READ or WRITE 
BYTE(3) READ or WRITE 



D1 6 Double byte transfers 

BYTE(0-1) READ or WRITE 
BYTE(2-3) READ or WRITE 



DS1* DSO* A01 LWORD* 



dhbm? dhbm? dxbm? dxbm? 



DLBM dhbm? DLBM dhbm? 
DLBM dhbm? DHBM dhbm? 



dhbm? DLBM DLBM dhbm? 
dhbm? DLBM DHBM dhbm? 



DLBM DLBM DLBM dhbm? 
DLBM DLBM DHBM dhbm? 
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Table 2-20. Use Of The DSr, DSO*, A01 , And LWORD* Unes To 
Select The Byte(s) Within A 4-Byte Group (cont'd) 



I 



Mnemonic Type of cycles 



DS1* DSO* A01 LWORD* 



D32 Quad byte transfers 

BYTE(0-3) READ or WRITE 



DLBM DLBM DLBM DLBM 



D08(EO) Single byte block transfers 
:BLT 

SINGLE BYTE 

BLOCK READ or WRITE <- 



-N0TE1 > dhbm? 



D1 6 :BLT Double byte block transfers 

DOUBLE BYTE 
BLOCK READ or WRITE 



DLBM DLBM NOTE 2 dhbm? 



D32 :BLT Quad byte block transfers 

QUAD BYTE 

BLOCK READ or WRITE 



DLBM DLBM DLBM DLBM 



D08(EO) 
:RMW 



Single byte RMW transfers 

BYTE(O) READ-MODIFY-WRITE DLBM dhbm? DLBM dhbm? 

BYTE(1)READ-M0DIFY-WRITE dhbm? DLBM DLBM dhbm? 

BYTE(2) READ-MODIFY-WRITE DLBM dhbm? DHBM dhbm? 

BYTE(3) READ-MODIFY-WRITE dhbm? DLBM DHBM dhbm? 



D16:RMW Double byte RMW transfers 

BYTE(0-1 ) READ-MODIFY-WRITE DLBM 
BYTE(2-3) READ-MODIFY-WRITE DLBM 



DLBM 
DLBM 



DLBM 
DHBM 



dhbm? 
dhbm? 



D32:RMW Quad byte RMW transfers 

BYTE(0-3) READ-MODIFY-WRITE DLBM DLBM DLBM DLBM 
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Table 2-20. Use Of The DS1*, DSO*, A01 , And LWORD* Lines To Select 
The Byte(s) Within A 4-Byte Group (conrd) 



Mnemonic Type of cycles 


DS1* 


DSO* 


A01 LWORD* 


D32:UAT Unaligned transfers 

BYTE(0-2) READ or WRITE 
BY lh(1-3) READ or WRITE 
BY lb(1 -2) READ or WRITE 


DLBM 

dhbm? 

DLBM 


dhbm? 

DLBM 

DLBM 


DLBM DLBM 
DLBM DLBM 
DHBM DLBM 



I 



Notes: 

1 . During Single byte block transfers, the two data strobes are alternately driven low . 
Either data strobe might be driven low on the first transfer. If the first accessed byte 
location is BYTE(O) or BYTE(2), then the MASTER drives DS1* to low first. If the first 
accessed byte location is BYTE(1) or BYTE(3), then it drives DSO* to low first. A01 is 
valid only on the first data transfer (i.e. until the SLAVE drives DTACK* or BERR* low 
the first time) and might be either high or low depending upon which byte the single 
byte block transfer begins with. If the first byte location is BYTE(O) or BYTE(1 ), then the 
MASTER drives A01 to low. If the first byte location is BYTE(2) or BYTE(3), then the 
MASTER drives A01 to high. 

An example of the use of DSO*, DS1*, A01, and LWORD* during a Single byte block 
transfer cycle which starts with BYTE(2) is given below: 







DS1* 


DSO* 


A01 


LWORD* 


First data transfer 
1 

Last data transfer 


BYTE(2) 
BYTE(3) 
BYTE(O) 
BYTE(1) 
BYTE(2) 


DLBM 
DHBM 
DLBM 
DHBM 
DLBM 


DHBM 
DLBM 
DHBM 
DLBM 
DHBM 


DHBM 
dxbm? 
dxbm? 
dxbm? 
dxbm? 


dhbm? 
dxbm? 
dxbm? 
dxbm? 
dxbm? 



2. During a Double byte block transfer, A01 is valid only on the first data transfer (i.e. 
until the SLAVE drives DTACK* or BERR* low the first time) and is driven either high or 
low depending upon what double byte group the double byte block transfer begins 
with. If the first double byte group is BYTE(0-1 ), then the MASTER drives A01 to low. If 
the first double byte group is BYTE(2-3), then the MASTER drives A01 to high. 
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Table 2-21 . Use Of The Data Bus Lines To Transfer Data 



1 



Mnemonic Type of cycles 


D24- 
D31 


Die- 
Das 


D08- 
D15 


DOO- 
D07 


ADO 


ADDRESS-ONLY 


dxbm? 


dxbm? 


dxbm? 


dxbm? 


D08(EO) 


Single even byte transfers 












BYTE(O) READ 
BYIh(2)READ 


dxbs? 
dxbs? 


dxbs? 
dxbs? 


DVBS 
DVBS 


dxbs? 
dxbs? 




BYTE(O) WRITE 
BY lh(2) WRITE 


dxbm? 
dxbm? 


dxbm? 
dxbm? 


DVBM 
DVBM 


dxbm? 
dxbm? 


D08(EO) 


Single odd byte transfers 










or 
D08(O) 


BYTE(1)READ 
BYIh(3)READ 

BY lb(1) WRITE 
BY 1 b(3) WRITE 


dxbs? 
dxbs? 

dxbm? 
dxbm? 


dxbs? 
dxbs? 

dxbm? 
dxbm? 


dxbs? 
dxbs? 

dxbm? 
dxbm? 


DVBS 
DVBS 

DVBM 
DVBM 


D16 


Double byte transfers 












BYTE(0-1)READ 
BYIt:(2-3)READ 


dxbs? 
dxbs? 


dxbs? 
dxbs? 


DVBS 
DVBS 


DVBS 
DVBS 




BYTE(0-1) WRITE 
BYTE(2-3) WRITE 


dxbm? 
dxbm? 


dxbm? 
dxbm? 


DVBM 
DVBM 


DVBM 
DVBM 


D32 


Quad byte transfers 












BYTE(0-3) READ 


DVBS 


DVBS 


DVBS 


DVBS 




BYTE(0-3) WRITE 


DVBM 


DVBM 


DVBM 


DVBM 
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Table 2-21 . Use Of The Data Bus Lines To Transfer Data (cont'd) 



Mnemonic 



Type of cycles 



D24- 
D31 



D16- 
D23 



D08- 
D15 



DOO- 
D07 



D08{EO) Single byte block transfers 
:BLT 

SINGLE BYTE BLOCK READ 

SINGLE BYTE BLOCK WRITE 



D1 6:BLT Double byte block transfers 

DOUBLE BYTE BLOCK READ 
DOUBLE BYTE BLOCK WRITE 



D32:BLT Quad byte block transfers 
QUAD BYTE BLOCK READ 
QUAD BYTE BLOCK WRITE 



D08(EO) 
:RMW 



Single byte RMW transfers 

BYTE(O) READ-MODIf=Y-WRITE 
BYTE{1) READ-MODIFY-WRITE 
BYTE(2) READ-MODIFY-WRITE 
BYTE{3) READ-MODIFY-WRITE 



dxbs? dxbs? < — Note 1 — > 
dxbm? dxbm? < — Note 1 — > 



dxbb? 
dxbb? 
dxbb? 
dxbb? 



D16:RMW Double byte RMW transfers 

BYTE(0-1) READ-MODIFY-WRITE dxbb? 
BYTE(2-3) READ-MODIFY-WRITE dxbb? 



D32:RMW Quad byte RMW transfers 

BYTE{0-3) READ-MODIFY-WRITE DVBB 



dxbb? 
dxbb? 
dxbb? 
dxbb? 



DVBB 
dxbb? 
DVBB 
dxbb? 



dxbb? 
dxbb? 



DVBB 
DVBB 



I 



dxbs? dxbs? DVBS DVBS 
dxbm? dxbm? DVBM DVBM 



DVBS DVBS DVBS DVBS 
DVBM DVBM DVBM DVBM 



dxbb? 
DVBB 
dxbb? 
DVBB 



DVBB 
DVBB 



DVBB DVBB DVBB 
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Table 2-21 . Use Of The Data Bus Lines To Transfer Data (cont'd) 



I 



Mnemonic Type of cycles 


D24- 
D31 


D16- 
D23 


D08- 
D15 


DOO- 
D07 


D32:UAT Unaligned transfers 










BYTE(0-2) READ 
BYTE(1-3)READ 
BYTE(1-2)READ 


dvbS 
dxbs? 
dxbs? 


DVBS 
DVBS 
DVBS 


DVBS 
DVBS 
DVBS 


dxbs? 
DVBS 
dxbs? 


BYTE(0-2) WRITE 
BYIb(1-3)WRITE 
BYTE(1-2)WRITE 


DVBM 
dxbm? 
dxbm? 


DVBM 
DVBM 
DVBM 


DVBM 
DVBM 
DVBM 


dxbm? 
DVBM 
dxbm? 



Note: 

1. During Single byte block transfers, data is transferred 8 bits at a time over D00-D07 
or D08-D1 5. A single byte block read example is given below: 





D08-D15 


D00-D07 


First data transfer 
1 
1 
1 

1 

Last data transfer 


DVBS 
dxbs? 
DVBS 
dxbs? 
DVBS 
dxbs? 
DVBS 


dxbs? 
DVBS 
dxbs? 
DVBS 
dxbs? 
DVBS 
dxbs? 
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Table 2-22. MASTER, SLAVE. And LOCATION MONITOR Timing Parameters 



PARAMETER 






LOCATION 


NUMBER 


MASTER 


SLAVE 


MONITOR 




See also 


See also 


See also 




Table 2-24 


Table 2-25 


Table 2-26 


MIN MAX 


MIN MAX 


MIN MAX 


1 









2 









3 


60 






4 


35 


10 


10 


5 


40 


30 


3 


6 










7 










8 


35 


10 




9 










10 





10 


10 


11 


40 


30 


30 


12 


35 


10 


10 


13 


10 


20 


20 


14 










15 










16 










17 


40 


30 


30 


18 










19 


40 


30 


30 


20 










21 










22 










23 


10 








24A 









248 









25 


25 






26 










27 


-25 







28 


30 2T 


30 




29 










30 










31 










32 




10 


10 


33 




30 


30 



1 



NOTES: 

1 . Ail times are in nanoseconds. 

2. T = the timeout value in microseconds. 
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Table 2-23. BUS TIMER, Timing Parameters (see also Table 2-27) 



a 



PARAMETER 
NUMBER 



MASTER 
MIN MAX 



28 
30 



T 




2T 



NOTE 



T = the time-out value in microseconds. 



Table 2-24. MASTER, Timing RULES And OBSERVATIONS 



Note: 

The numbers correspond to the timing parameters specified in Table 2-22. 

1. RULE 2.27: 

When taking control of the VMEbus, the MASTER MUST NOT drive any of 
JACK*, AM0-AM5, A01-A31, LWORD*, D00-D31, WRITE*, DSO*, DS1*, or AS* 
until after the previous MASTER allows AS* to rise above the low level. 

OBSERVATION 2.35: 

Chapter 3 describes how a MASTER'S REQUESTER is granted use of the 
VMEbus. 

2. RULE 2.28: 

When taking control of the VMEbus, the MASTER MUST NOT drive any of 
JACK*, AM0-AM5, A01-A31, LWORD*, D00-D31, WRITE*, DSO*, DS1*, or AS* 
until after its REQUESTER is granted the bus. 

OBSERVATION 2.36: 

Chapter 3 describes how a MASTER'S REQUESTER is granted use of the 
VMEbus. 

3. RULE 2.29: 

When taking control of the VMEbus, the MASTER MUST NOT drive AS* low 
until this time after the previous MASTER allows AS* to rise above the low level. 

OBSERVATION 2.37: 

RULE 2.29 ensures that timing parameter 5 for SLAVES is guaranteed when 
there is an interchange of the DTB mastership. 
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4. RULE 2-30: 

The MASTER MUST NOT drive AS* low until JACK* has been high, and the 
required lines among A01-A31, AM0-AM5, and LWORD* have been valid for 
this minimum time. 

OBSERVATION 2.38: 

Tables 2-19 and 2-20 specify the lines among A01-A31, AM0-AM5, and 
LWORD* that a MASTER is required to drive. 

5. RULE 2.31: 

When using the DTB for two consecutive cycles, the MASTER MUST NOT 
drive AS* low until it has been high for this minimum time. 

6. RULE 2.32: 

After a read cycle, the MASTER MUST NOT drive any of D00-D31 until both 
DTACK* and BERR* are high. 

7 RULE 2.33: 

During read "cycles, the MASTER MUST NOT drive DBA* low until it has 
released all of D00-D31 . 

8 RULE 2.34: 

During write" cycles, the MASTER MUST NOT drive DSA* low until the 
required lines among D00-D31 have been valid for this minimum time. 

OBSERVATION 2.39: 

Table 2-21 specifies the lines among D00-D31 that a MASTER is required to 
drive. 

9 RULE 2.35: 

The MASTER MUST NOT drive DSA* low until both DTACK* and BERR* are 
high. 

10. RULE 2.36: 

The MASTER MUST NOT drive DSA* low until it has driven AS* low. 

11 RULE 2.37: 

The MASTER MUST NOT drive DSA* low until DSO* and DS1* have both 
been simultaneously high for this minimum time. 

12. RULE 2.38: 

The MASTER MUST NOT drive DSA* low until WRITE* has been valid for this 

minimum time. 

13 RULE 2 39: 

During cycles where the MASTER drives both data strobes low, it MUST drive 
DSB* low within this maximum time after it drives DSA* low. 
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OBSERVATION 2.40: 

Timing parameter 13 does not apply to transfers where only one data strobe is 
driven low. 

14. RULE 2.40: 

During all data transfer cycles, except read-modify-write cycles, the MASTER 
MUST hold the address valid and maintain the appropriate level on LWORD* 
until it detects the first falling edge on DTACK* or BERR*. 

OBSERVATION 2.41: 

During all data transfer cycles, except block transfer and read-modify-write 
cycles, there will be only one falling edge on DTACK* or BERR*. 

15. RULE 2.41: 

During read-modify-write cycles, the MASTER MUST hold the address valid 
and maintain the appropriate level on LWORD* until it detects the second falling 
edge on DTACK* or BERR*. 

16. RULE 2.42: 

During all data transfer cycles, the MASTER MUST maintain a valid address 
modifier code, and ensure that lACK* stays high until it detects the last falling 
edge on DTACK* or BERR*. ^ 

OBSERVATION 2.42: 

During all data transfer cycles, except block transfer and read-modify-write 
cycles, there will be only one falling edge on DTACK* or BERR*. 

17. RULE 2.43: 

During ADDRESS-ONLY cycles, the MASTER MUST NOT change the levels 
on JACK*, A01-A31, AM0-AM5, and LWORD* for this minimum time after it 
drives AS* low. 

18. RULE 2.44: 

During all data transfer cycles, the MASTER MUST hold AS* low untilit detects 
the last falling edge on DTACK* or BERR*. 

19. RULE 2.45: 

The MASTER MUST hold AS* low for this minimum time. 

20. RULE 2.46: 

Once a MASTER has driven DSA* low, it MUST maintain that line low until it 
detects DTACK* or BERR* low. 

21. RULE 2.47: 

Once a MASTER has driven DSB* low, it MUST maintain that line low until it 
detects DTACK* or BERR* low. 
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22. RULE 2.48: 

During write cycles, once the MASTER has driven DSA* low, it MUST not 
change any of D00-D31 until it detects DTACK* or BERR* low. 

23. RULE 2.49: 

Once a MASTER has driven DSA* low, it MUST NOT change the level on the 
WRITE* line, until this minimum time after both data strobes are high. 

24A. RULE 2.50: 

IF the MASTER drives or releases AS* to high after its REQUESTER 

releases BBSY*, 
THEN it MUST release JACK*, AM0-AM5, A01-A31, LWORD*, D00-D31, 

WRITE*, DSO* and DS1* before allowing AS* to rise above the low 

level. 

OBSERVATION 2.43: 

Chapter 3 describes how a MASTER'S REQUESTER releases the BBSY* line. 

24B- RULE 2.51: 

IF the MASTER drives or releases AS* to high before its REQUESTER 

releases BBSY*, 
THEN it MUST release AS*, JACK*, AM0-AM5, A01-A31 , LWORD*, D00-D31 , 

WRITE*, DSO* and DS1* before allowing its REQUESTER to release 

BBSY*. 

OBSERVATION 2.44: 

Chapter 3 describes how a MASTER'S REQUESTER releases the BBSY* line. 

25. RULE 2.52: 

IF the MASTER drives or releases AS* to high after its REQUESTER 

releases BBSY*, 
THEN it MUST release AS* within this time after allowing it to rise above the 

low level. 

OBSERVATION 2.45: 

Chapter 3 describes how a MASTER'S REQUESTER releases the BBSY* line. 

26. OBSERVATION 2.46: 

Timing parameter 26 guarantees that during read cycles, the data bus will not 
be driven until the MASTER drives DSA* low. 

27. OBSERVATION 2.47: 

During read cycles, the MASTER is guaranteed that the data bus will be valid 
within this time after DTACK* goes low. This time does not apply to cycles 
where the SLAVE drives BERR* low instead of DTACK*. 



I 
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28. OBSERVATION 2.48: 

The MASTER is guaranteed that neither DTACK* nor BERR* will go low until 
this minimum time after it drives DBA* low. The BUS TIMER guarantees the 
MASTER that if DTACK* has not gone low after its timeout period has elapsed, 
and within twice its timeout period, then the BUS TIMER will drive BERR* low. 

29. OBSERVATION 2.49: 

During read cycles, the MASTER is guaranteed that the data bus will remain 
valid until it drives DSA* high. 

30. OBSERVATION 2.50: 

Timing parameter 30 guarantees that neither DTACK* nor BERR* will go high 
until the MASTER drives both DSO* and DS1* high. 

31. OBSERVATION 2.51: 

During read cycles, the MASTER is guaranteed that the data bus has been 
released by the time DTACK* and BERR* are high. 
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Table 2-25. SLAVE, Timing RULES And OBSERVATIONS 

Note: 

The numbers correspond to the timing parameters specified in Table 2-22. 

4. OBSERVATION 2.52: 

All SLAVES are guaranteed that JACK*, A01-A31, AM0-AM5, and LWORD* 
have been valid for this minimum time when they detect a falling edge on AS*. 

5. OBSERVATION 2.53: 

All SLAVES are guaranteed this minimum high time on AS* between DTB 
cycles. 

6. OBSERVATION 2.54: 

During read cycles, the responding SLAVE is guaranteed that none of D00-D31 
will be driven by any other module until the responding SLAVE releases 
DTACK* and BERR* to high. 

7. OBSERVATION 2.55: 

During read cycles, the responding SLAVE is guaranteed that the data bus will 
be released by all other modules by the time DSA* goes low. 

8. OBSERVATION 2.56: 

During write cycles, the responding SLAVE is guaranteed that the data bus has 
been valid for this minimum time when it detects a falling edge on DSA*. 

9. OBSERVATION 2.57: 

The responding SLAVE is guaranteed that neither DSO* nor DS1* will go low 
until DTACK* and BERR* from the previous cycle have gone high. 

10. OBSERVATION 2.58: 

Due to bus skew, SLAVES on the DTB might detect a falling edge on DSA* 
before detecting the falling edge on AS*. However, SLAVES are guaranteed 
that a falling edge on DSA* will not precede the falling edge on AS* by more 
than this time. 

11. OBSERVATION 2.59: 

SLAVES are guaranteed this minimum time during which both data strobes are 
simultaneously high between consecutive data transfers. 

12. OBSERVATION 2.60: 

SLAVES are guaranteed that WRITE* has been valid for this minimum time 
before a falling edge on DSA*. 

13. OBSERVATION 2.61: 

IF both data strobes are going to be driven low, 

THEN the responding SLAVE is guaranteed that DSB* will go low within this 
maximum time after DSA* has gone low. 
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14. OBSERVATION 2.62: 

During all data transfer cycles except readmodifywrite cycles, the responding 
SLAVEis guaranteed that the address and LWORD* remain valid until it drives 
DTACK* or BERR* low for the first time, provided that it does so within the bus 
timeout period. 

15. OBSERVATION 2.63: 

During all readmodifywrite cycles, the responding SLAVE is guaranteed that the 
address and LWORD* remain valid until it drives DTACK* or BERR* low for the 
second time, provided that it does so within the bus timeout period. 

16. OBSERVATION 2.64: 

The responding SLAVE is guaranteed that JACK* and AM0-AM5 remain valid 
until it drives DTACK* or BERR* low for the last time, provided that it does so 
within the bus timeout period. 

17. OBSERVATION 2.65: 

SLAVES are guaranteed that lACK*, A01-A31, AM0-AM5, and LWORD* will 
remain valid for this minimum time after the falling edge of AS*. During 
ADDRESS-ONLY cycles this time is guaranteed by the MASTER. During all 
other cycle types, this time is derived from timing parameters 10, 14, 16, and 28. 

18. OBSERVATION 2.66: 

The responding SLAVE is guaranteed that AS* will remain low until it drives 
DTACK* or BERR* low, provided that it does so within the bus timeout period. 

19. OBSERVATION 2.67: 

SLAVES are guaranteed that the AS* will remain low for this minimum time. 

20. OBSERVATION 2.68: 

The responding SLAVE is guaranteed that once DSA* goes low, it will remain 
low until it drives DTACK* or BERR* low, provided that the SLAVE does so 
within the bus timeout period. 

21. OBSERVATION 2.69: 

The responding SLAVE is guaranteed that once DSB* goes low, it will remain 
low until it drives DTACK* or BERR* low, provided that the SLAVE does so 
within the bus timeout period. 

22. OBSERVATION 2.70: 

During write cycles, the responding SLAVE is guaranteed that the data bus will 
remain valid until it drives DTACK* or BERR* low, provided that it does so within 
the bus timeout period. 

23. OBSERVATION 2.71: 

The responding SLAVE is guaranteed that the WRITE* line remains valid until 
both data strobes are high. 
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26. RULE 2.53: 

During read cycles, the responding SLAVE MUST NOT drive the data bus 
until DSA* goes low. 

27. RULE 2.54: 

During read cycles, the responding SLAVE MUST NOT drive DTACK* before 
it drives the data lines with valid data. 

OBSERVATION 2.72: 

RULE 2.54 does not apply to cycles where the responding SLAVE drives 
BERR* low instead of DTACK*. 

28. RULE 2.55 

The responding SLAVE MUST wait this minimum time after DSA* goes low 
before driving DTACK* or BERR* low. 

29. RULE 2.56: 

During read cycles, once the responding SLAVE has driven DTACK* low, it 
MUST NOT change D00D31 until DSA* goes high. 

30. RULE 2.57: 

Once the responding SLAVE has driven DTACK* or BERR* low, it MUST NOT 
release it until it detects both DSO* and DSr high. 

31. RULE 2.58: 

During read cycles, the responding SLAVE MUST release all of D00-D31 
before releasing DTACK* or BERR* to high. 

32. OBSERVATION 2.73: 

SLAVES are guaranteed that JACK*, LWORD*, A00-A31, and AM0-AM5 have 
been valid for this minimum time when they detect a falling edge on DSA*. This 
time is derived from timing parameters 4 and 10. 

33. OBSERVATION 2.74: 

During data transfer cycles, SLAVES are guaranteed that DSO* and/or DSr 
will remain low for at least this minimum time. This time is derived from timing 
parameter 28, where the responding SLAVE is required to wait a minimum time 
before driving BERR* or DTACK* to low. 
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Table 2-26. LOCATION MONITOR, Timing Observations 

Note: 

The numbers correspond to the timing parameters specified in Table 2-22. 

4. OBSERVATION 2.75: 

The LOCATION MONITOR is guaranteed that lACK*, AQ1-A31, AM0-AM5, and 
LWORD* have been valid for this minimum time when it detects a fallinq edae 
on AS*. ^ 

5. OBSERVATION 2.76: 

The LOCATION MONITOR is guaranteed this minimum high time on AS* 
between DTB cycles. 

10. OBSERVATION 2.77: 

Due to bus skew, LOCATION MONITORS on the DTB might detect a falling 
edge on DSA* before detecting the falling edge on AS*. However, The 
LOCATION MONITOR is guaranteed that the falling edge on DSA* will not 
precede the falling edge on AS* by more than this time. 

11. OBSERVATION 2.78: 

The LOCATION MONITOR is guaranteed this minimum time during which both 
data strobes are simultaneously high between consecutive data transfers. 

12. OBSERVATION 2.79: 

The LOCATION MONITOR is guaranteed that WRITE* has been valid for this 
minimum time when it detects a falling edge on DSA*. 

13. OBSERVATION 2.80: 

IF both data strobes are going to be driven low, 

THEN the LOCATION MONITOR is guaranteed that DSB* will go low within 
this maximum time after DSA* has gone low. 

17. OBSERVATION 2.81: 

The LOCATION MONITOR is guaranteed that lACK*, A01-A31, AM0-AM5, and 
LWORD* will remain valid for this minimum time after the falling edge of AS*. 
During ADDRESS ONLY cycles this time is guaranteed by the MASTER. 
During all other cycle types, this time is derived from timing parameters 10, 14, 
16, and 28. 

19. OBSERVATION 2.82: 

The LOCATION MONITOR is guaranteed that the AS* will remain low for this 
minimum time. 

23. OBSERVATION 2.83: 

The LOCATION MONITOR is guaranteed that the WRITE* line remains valid 
until both data strobes go high. 
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32. OBSERVATION 2.84: 

The LOCATION MONITOR is guaranteed that lACK*. LWORD*, A01-A31, and 
AM0-AM5 have been valid for this minimum time when it detects a falling edge 
on DSA*. 

33. OBSERVATION 2.85: 

During data transfer cycles, the LOCATION MONITOR is guaranteed that DSO 
and/or DSr will remain low for at least this minimum time. This time is derived 
from timing parameter 28, where the responding SLAVE is required to wait a 
minimum time before driving BERR* or DTACK* to low. 



I 



Note: 



Table 2-27. BUS TIMER, Timing RULES 
The numbers correspond to the timing parameters specified in Table 2-23. 



28. RULE 2.59: 

The BUS TIMER MUST wait at least its timeout time, but no longer than twice 
its timeout time, after the first data strobe goes low before driving BERR* low. 

30. RULE 2.60: 

Once it has driven BERR* low, the BUS TIMER MUST NOT release BERR* 
until it detects both DSO* and DS1* high. 
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Figure 2-12. Address Broadcast Timing 
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Figure 2-15. MASTER. SLAVE, And LOCATION MONITOR Address Broadcast Timing 
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Figure 2-16. MASTER, SLAVE. And LOCATION MONITOR.Data Transfer Timing 
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Figure 2-16. MASTER, SLAVb, and LOCATION MONITOR Data Transfer 

Timing (cont'd) 
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Figure 2-17. MASTER, SLAVE, and LOCATION MONITOR Data Transfer Timinq 
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Figure 2-18. MASTER, SLAVE, And LOCATION MONITOR Data Transfer Timing 
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Figure 2-18. MASTER, SLAVE, And LOCATION MONITOR Data Transfer 

Timing (cont'd) 
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Quad Byte Block Write 
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Figure 2-19. MASTER, SLAVE, And LOCATION MONITOR Data Transfer Timing 
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Figure 2-19. MASTER.SLAVE, And LOCATION MONITOR Data Transfer 

Timing (cont'd) 
Byte(0-1) Write 
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Double Byte Block Write 
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Figure 2-20. MASTER, SLAVE, And LOCATION MONITOR Data Transfer Timing 

Single Byte RMW Cycles 
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Figure 2-21 . MASTER, SLAVE, And LOCATION MONITOR Data Transfer Timing 
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Figure 2-24. Data Strobe Intercycle Timing 

A cycle where one data strobe goes low followed by a cycle where 

one or both data strobes go low 
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Figure 2-26. MASTER DTB Control Transfer Timing 



103 



DATA TRANSFER BUS 



I 



104 



CHAPTER 3 
DATA TRANSFER BUS ARBITRATION 



3.1 BUS ARBITRATION PHILOSOPHY 

As microprocessor costs decrease, it is becoming more cost effective to design 
systems with multiple processors sharing global resources. 

The most fundamental of these global resources is the Data Transfer Bus through 
which all other global resources are accessed. Therefore, any system that supports 
multiprocessing needs to provide an efficient allocation method for the Data Transfer 
Bus. Because speed of allocation is vital, a hardware allocation scheme is the only 
practical alternative. The VMEbus meets this need with its Arbitration subsystem. 
(See Figure 3-1). 

The VMEbus arbitration subsystem: 

a. Prevents simultaneous use of the bus by two MASTERS. 

b. Schedules requests from multiple MASTERS for optimum bus use. 

3.1-1 Types Of Arbitration 

When several boards request use of the DTB simultaneously, the arbitration 
subsystem detects these requests and grants the bus to one board at a time. The 
decision of which board is granted the bus first depends upon what scheduling 
algorithm is used. Many algorithms are possible. The VMEbus describes three: 
prioritized, round-robin, and single level. 

Prioritized arbitration assigns the bus according to a fixed priority scheme where each 
of four bus request lines has a priority from highest (BR3*) to lowest (BRO*). 

Round-robin arbitration assigns the bus on a rotating priority basis. When the bus is 
granted to the REQUESTER on bus request line "BR(n)*", then the highest priority for 
the next arbitration is assigned to bus request line "BR(n-1)*". 

Single level arbitration only accepts requests on BR3*, and relies on BR3*'s bus grant 
daisy-chain to arbitrate the requests. 

PERMISSION 3.1: 

Scheduling algorithms other than priority, round-robin, or single level MAY be used. 
For example, an ARBITER'S algorithm might give highest priority to BR3*, but grant the 
bus to BRO* through BR2* on a round-robin basis. 
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Figure 3-1. Arbitration Bus Functional Block Diagram 
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3.2 ARBITRATION BUS LINES 



The Arbitration Bus consists of six bused VMEbus lines and four daisy-chained lines. 
These daisy-chained lines require special signal names. The signals entering each 
board are called "Bus Grant IN" lines (BGxIN*), while the signals leaving each board 
are called "Bus Grant OUT" lines (BGxOUT*). The lines which leave slot n as BGxOUT* 
enter slot n+1 as BGxIN*. This is illustrated in Figure 3-2. 

OBSERVATION 3.1: 

In all descriptions in this chapter, the terms BRx*, BGxIN*, and BGxOUT* are used to 
describe the bus request and bus grant lines, where x takes on any value from zero to 
three. 

In the VMEbus arbitration system, a REQUESTER module drives the following lines: 

1 bus request line (one of BRO* through BR3*) 

1 bus grant out line (one of BGOOUT* through BG30UT*) 

1 bus busy line (BBSY*) 

RULE 3.1: 

IF a VMEbus board does not generate bus requests on some bus request levels, 

THEN it MUST propagate the daisy-chain signals for those levels from its BGxIN* 
lines to its respective BGxOUT* lines. 

PERMISSION 3.2: 

The propagation for the unused lines of the bus grant daisy-chain can be done using 
jumpers or active logic. The latter approach allows selection of the request level under 
software control, while the former results in faster propagation through the daisy-chain. 

Three types of ARBITERS are described in the VMEbus standard. They are: 

PRIoritized (PR!) 

Round-Robin-Select (RRS) 

SinGLe level (SGL) 

The operation of these three types of ARBITERS is described in Section 3.3. 

A PRI ARBITER drives the following: 
1 bus clear line (BGLR*) 

4 bus grant lines (Slot 1 BGOIN* through BG3IN*) if the ARBITER'S board 

also has a REQUESTER. 
(Slot 1 BGOOUT* through BG30UT*) If the ARBITER'S 
board does not have a REQUESTER. 

An RRS ARBITER drives the four Slot 1 BGxIN* or BGxOUT* lines and, optionally, the 
BGLR* line. 

A SGL ARBITER drives only BG3IN* or BG30UT* at slot 1 . 
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Figure 3-2. Illustration Of The Daisy-Chained Bus Grant Lines 
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Two additional lines are connected with the arbitration system during power-up and 
power-down sequencing: SYSRESET*, and ACFAIL*. While their impact on the 
arbitration system is included in this chapter, these lines will be discussed further in 
Chapter 5. 

3.2.1 Bus Request And Bus Grant Lines 

The bus request lines are used by each REQUESTER to request use of the DTB. The 
bus grant lines allow the ARBITER to award use of the bus. It does this by driving a 
bus grant daisy-chain line low. This low level propagates down the daisy-chain, 
typically passing through several boards in the process. If a board never uses a 
particular request/grant level, the signal is passed through that board. Where the 
board uses a request/grant level x, the corresponding signal BGxIN* is gated on 
board. If its on-board, REQUESTER is currently requesting the DTB on that level, it 
does not pass the low level on to its BGxOUT*. OthenA/ise, it passes on the low level. 

RULE 3.2: 

IF a VMEbus backplane slot is not occupied by a board, and if there are boards 

farther down the daisy-chain, 
THEN jumpers MUST be installed at the empty slot to pass through the daisy-chain 

signal. 

OBSERVATION 3.2: 

The backplane mechanical specification in Chapter 7 describes a provision for the 
installation of jumpers at each slot. 

RULE 3.3: 

The ARBITER MUST always be located in slot 1. 

3.2.2 Bus Busy Line (BBSY*) 

Once a REQUESTER has been granted control of the Data Transfer Bus via the bus 
grant daisy-chain, it drives BBSY* low. It then has control of the DTB until it releases 
BBSY*, allowing the ARBITER to grant the DTB to some other REQUESTER. 

3.2.3 Bus Clear Line (BCLR*) 

The PR! ARBITER drives BCLR* low to inform the MASTER, currently in control of the 
DTB, when a higher priority request is pending. The current MASTER does not have 
to relinquish the bus within any prescribed time limit. It can continue transferring data 
until it reaches an appropriate stopping point, and then allow its on-board 
REQUESTER to release BBSY*. 

PERMISSION 3.3: 

Although RRS ARBITERS are not required to drive the BCLR* line they MAY do so. 
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SUGGESTION 3.1: 

IF a RRS ARBITER drives the BCLR* line low, 

THEN design it to do so whenever there is a request pending on any of the non- 
granted bus request lines. 

3.3 FUNCTIONAL MODULES 

The arbitration subsystem is composed of several modules: 

a. One ARBITER 

b. One or more REQUESTERS 

Figures 3-3 and 3-4 provide block diagrams for the two types of Arbitration Bus 
modules. 

RULE 3.4: 

Output signal lines shown with solid lines in Figure 3-3 and 3-4 MUST be driven by 
the module, unless it would always drive them high. 

RULE 3.5: 

Input signal lines shown with solid lines in Figures 3-3 and 3-4 MUST be monitored 
and responded to in the appropriate fashion. 

OBSERVATION 3.3: 

RULES and PERMISSIONS for driving and monitoring the signal lines shown with 
dotted lines in Figures 3-3 and 3-4 are given in Tables 3-1 and 3-2. 

OBSERVATION 3.4: 

IF an output signal line is not driven, 

THEN terminators on the backplane ensure that it is high. 

OBSERVATION 3.5: 

Although SYSRESET* and ACFAIL* are not specified as part of the Arbitration Bus, 
they are important here because MASTERS, which are paired with REQUESTERS, 
respond to these signal lines. (SYSRESET* and ACFAIL* are driven by the POWER 
MONITOR module which is discussed in Chapter 5.) 

3.3.1 ARBITER 

The ARBITER is a functional module that decides which REQUESTER should be 
granted control of the DTB when several request it simultaneously. There are many 
possible algorithms that could be used to make this decision. Three types of 
ARBITERS are described in this specification: a prioritized (PRI) ARBITER, a round- 
robin select (RRS) ARBITER, and a single level (SQL) ARBITER. 

An ARBITER responds to incoming bus requests and grants the DTB to the appropriate 
REQUESTER with one of the bus grant lines. 
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When the ARBITER detects BBSY* high, and after it detects one or more bus requests, 
it issues a bus grant, corresponding to the highest priority bus request. 

When the REQUESTER receives the bus grant, it drives BBSY* low and signals to its 
on-board MASTER or INTERRUPT HANDLER that It has been granted the DTB. After 
its on-board MASTER or INTERRUPT HANDLER finishes using the DTB, the 
REQUESTER releases BBSY*. The resulting rising edge of BBSY* enables the 
ARBITER to issue another bus grant, based upon the levels of the bus request lines at 
that time. 

In addition to the arbitration provided by the ARBITER, a secondary level of arbitration 
is provided by the bus grant daisy-chains. Because of these daisy-chains, 
REQUESTERS sharing a common request line are prioritized by slot position. The 
REQUESTER closest to slot 1 has the highest priority. 

SQL ARBITERS respond only to bus requests on BR3* and depend on the 
BG3IN*/BG30UT* daisy-chain to do the arbitration. 

The PRI ARBITER prioritizes the four bus request lines, from BRO* (the lowest) to BR3* 
(the highest), and responds with BGOIN* through BG3IN*, as appropriate. A PRI 
ARBITER also informs any MASTER, currently in control of the bus, when a higher 
level request is pending by driving BOLR* low. 

To visualize an RRS ARBITER, consider a mechanical switch being driven by a 
stepping motor. Each position on the switch connects a bus request line to its 
corresponding bus grant line. When the bus is busy, the switch is stopped on the 
current level. Upon release of the bus, the switch steps one position lower (i.e., from 
BR(n)* to BR(n-1)*) and tests for a request. It continues this scanning operation until a 
request is found, sending a bus grant over the appropriate line. 

PERMISSION 3.4: 

An ARBITER MAY be designed with built-in time-out feature that causes it to withdraw 
a bus grant if BBSY* is not driven low by a REQUESTER within a prescribed time. 

OBSERVATION 3.6: 

The time used by the ARBITER allowed by PERMISSION 3.4 needs to be longer than 
the longest possible bus grant daisy-chain propagation delay time, plus the time the 
slowest REQUESTER takes to generate BBSY*. 

RULE 3.6: 

Except for a time-out situation where no REQUESTER responds, once the ARBITER 
grants the bus to a REQUESTER it MUST NOT generate a new bus grant before that 
REQUESTER generates a rising edge on the BBSY* line. (The REQUESTER 
generates a rising edge by driving BBSY* low and then releasing it.) 

OBSERVATION 3.7: 

IF an ARBITER uses a "snapshot" of the request lines taken prior to the rising 

edge of BBSY*, 
THEN it might grant the bus to a REQUESTER that has since removed its request. 
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Note: The RULES and PERMISSIONS for monitoring and driving the dotted lines are 
given in Table 3-1 . 



Figure 3-3. Block Diagram: ARBITER 
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Table 3-1 . RULES And PERMISSIONS That Specify The Use Of The 
Dotted Lines By The Various Types Of ARBITERS Defined By This Document 



Type of 
ARBITER 


Use of dotted line 


SQL 


MUST drive slot 1 BG3IN*. 

MUST ensure slot 1 BG01 N* - BG2IN* are high. 

MUST monitor BR3*. 

MAY or MAY not drive BCLR*, or slot 1 BG0!N*-BG2IN 
MAY or MAY not monitor BR0*-BR2*. 


RRS 


MUST drive slot 1 BG0IN*-BG3IN*. 
MUST monitor BR0*-BR3*. 

MAY or MAY not drive BCLR*. 


PRI 


MUST drive slot 1 BG0IN*-BG3IN*, and BCLR*. 
MUST monitor BR0*-BR3*. 



B 



3.3.2 REQUESTER 

Each REQUESTER in the system: 

a- Monitors the DEVICE WANTS BUS from its on-board MASTER or INTERRUPT 
HANDLER and generates a bus request when the DTB is needed. 

b. If it detects a low level on its BGxIN* line, and its on-board MASTER or INTERRUPT 
HANDLER does not need the DTB, then it passes on that low level to its BGxOUT* 

c. If it detects a low level on its BGxIN* line, and its on-board MASTER or INTERRUPT 
HANDLER needs the DTB, it generates an on-board DEVICE GRANTED BUS 
signal to indicate the DTB is available, and drives the BBSY* signal low. 

Two types of REQUESTERS are described in this specification: a Release When Done 
(RWD) REQUESTER and a Release On Request (ROR) REQUESTER. 

The RWD REQUESTER releases BBSY* when the MASTER or INTERRUPT 
HANDLER drives the on-board DEVICE WANTS BUS signal false. 
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The ROR REQUESTER does not release BBSY* when its on-board DEVICE WANTS 
BUS signal goes false unless some other REQUESTER on the bus drives one of the 
bus request lines low. It monitors the four bus request lines and releases BBSY* only 
if another bus request is pending. ROR REQUESTERS reduce the number of 
arbitrations initiated by a MASTER which is generating a large percentage of the bus 
traffic. See Figure 3-4. 

Assuming that the REQUESTER'S DEVICE WANTS BUS input is true, when it 
receives a bus grant it does 3 things: 

a. It drives BBSY* to low. 

b. It releases its low on BRx. 

0. It drives the DEVICE GRANTED BUS on-board signal true, allowing the MASTER 
or INTERRUPT HANDLER to initiate bus transfers. 

These events might occur in any order. It is even possible, although meaningless, that 
the MASTER or INTERRUPT HANDLER might not use the bus in response to this 
particular grant. 

However, the following RULES apply: 

RULE 3.7: 

The REQUESTER MUST drive BBSY* to low for at least 90 nanoseconds. 

RULE 3.8: 

The REQUESTER MUST release bus request to high. 

RULE 3.9: 

The REQUESTER MUST maintain BBSY* low for at least 30 nanoseconds after it 
releases its bus request. 

OBSERVATION 3.8: 

The 30 nanosecond delay between the bus request's rising edge and the BBSY* 
rising edge ensures that the ARBITER does not mistakenly interpret the old bus 
request as a new one and issue another grant. 

RULE 3.10: 

The REQUESTER MUST hold BBSY* low ijntil its bus grant goes high. 

OBSERVATION 3.9: 

RULE 3.10 ensures that the BBSY* transition to low has been seen by the ARBITER 
and that all segments of the bus grant daisy-chain have returned to high, in 
preparation for the next arbitration. 

PERMISSION 3.5: 

IF a REQUESTER has a bus request pending and, if it sees some other 

REQUESTER drive BBSY* low, 
THEN it MAY withdraw its request by releasing the bus request line. 
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RULE 3.11: 

IF a REQUESTER withdraws a bus request without having first been granted the 

bus, 
THEN it MUST wait to do so until BBSY* goes low and it MUST do so within 50 

nanoseconds after BBSY* goes low. 



SUGGESTION 3.2: 

Design REQUESTERS so that they pass on the bus grant daisy-chain as fast as 
possible after receipt of a bus grant. This will improve system performance. 



B 
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Note: The RULES and PERMISSIONS for monitoring tlie dotted lines are given in 
Table 3-2. 



Figure 3-4. Block Diagram: REQUESTER 
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Table 3-2. RULES and PERMISSIONS That Specify The Use Of The 
Dotted Lines By The Various Types Of REQUESTERS Defined By This Document 



B 



Type of 
REQUESTER Use of clotted line 



RWD MAY or MAY not monitor BR0*-BR3* 



ROR MUST monitor BR0*-BR3*. 



3.3.3 Data Transfer Bus MASTER 

3.3.3.1 Release Of The DTB 

The bus arbitration protocol determines how and when the DTB is granted to the 
various MASTERS and INTERRUPT HANDLERS in the system. It does not, however, 
control when MASTERS and INTERRUPT HANDLERS release the DTB. 

MASTERS and INTERRUPT HANDLERS use several criteria in deciding when to 
release the DTB. INTERRUPT HANDLERS give up the bus after their interrupt 
acknowledge cycle. MASTERS give up the bus when they finish their data transfers. 

Some MASTERS also monitor the ACFAIL* and BCLR* VMEbus signals. Both of these 
signals inform the MASTER that the DTB is needed for some higher priority activity. In 
the case of BCLR*, the MASTER'S design determines how long it takes to release the 
bus. For example, a MASTER on a disk controller board might not be able to 
relinquish the bus during a disk sector transfer without loss of data, so it might keep the 
bus until the sector transfer is finished. ACFAIL* informs the MASTER that an an AC 
power loss has been detected, and whatever problems the MASTER will face in 
surrendering the bus are insignificant compared to the needs of the total system. 

RECOMMENDATION 3.1: 

Design MASTERS to release the DTB within 200 microseconds after ACFAIL* goes 
low, except to participate in the ensuing power failure activities. 

OBSERVATION 3.10: 

The 200 microsecond specified in RECOMMENDATION 3.1 is intended to provide time 
for an orderly shut-down of the system. 

Whatever criteria are used to decide when to release the DTB, arbitration is done 
before some other MASTER or INTERRUPT HANDLER begins using it. This 
arbitration takes place either during the last data transfer or after that transfer, 
depending on how much notice the MASTER or INTERRUPT HANDLER gives to its 
on-board REQUESTER. 
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PERMISSION 3.6: 

MASTERS and INTERRUPT HANDLERS MAY release the DTB either during or after 
their last data transfer. 

For example, if the MASTER notifies its on-board REQUESTER that it no longer wants 
the bus during its last data transfer, the REQUESTER releases BBSY* and arbitration 
takes place during the last transfer. But if the MASTER waits until the last transfer has 
completed before signaling its on-board REQUESTER, the DTB remains idle while the 
arbitration is done. (This was illustrated in Section 2.5.1) 

Chapters 2 and 4 contain RULES that pertain to the release of the DTB. 

SUGGESTION 3.3: 

Design block transfer MASTER boards so that they signal their REQUESTER to 
release BBSY* during the last data strobe of the block transfer, if it is released at the 
beginning of the block transfer, high priority bus requests initiated during the block 
transfer might not be taken into account by the ARBITER until the next arbitration cycle. 

3.3.3.2 Acquisition Of The DTB 

To ensure that no DTB line is ever driven to opposite states by two MASTERS or 
INTERRUPT HANDLERS, when these modules take control of the DTB they are 
constrained by the following rule: 

RULE 3.12: 

When a MASTER or INTERRUPT HANDLER is given control of the DTB by its on- 
board REQUESTER, it MUST wait until it detects AS* high before turning on its DTB 
drivers. 

OBSERVATION 3.11: 

IF the previous MASTER or INTERRUPT HANDLER releases the bus DURING its 

j^e+ rjgta transfsr 
THEN RULE 3.12 ensures that the data transfer will be finished before the new 

MASTER or INTERRUPT HANDLER starts using the DTB. (If the previous 

MASTER or INTERRUPT HANDLER waited until the data transfer was finished 

before releasing the bus, AS* will already be high.) 

3.3.3.3 Other Information 

RECOMMENDATION 3.2: 

To allow for prompt servicing of interrupt requests and for optimum use of the DTB, 
design MASTERS so that they release the DTB as soon as possible after they detect 
BCLR* low. 

PERMISSION 3.7: ^^^, .^on-,^„ u 

A MASTER or INTERRUPT HANDLER MAY have more than one REQUESTER, where 
each REQUESTER generates bus requests on a different bus request line. 
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OBSERVATION 3.12: 

Where a MASTER or INTERRUPT HANDLER has two or more REQUESTERS, it can 
do high priority data transfers using one REQUESTER and low priority transfers using 
another REQUESTER. i- j » 

3.4 TYPICAL OPERATION 
^^ 3.4.1 Arbitration Of Two Different Levels Of Bus Request 

19 Sii^Mlo-;!-,?!^^ ^"® illustrate the sequence of events that takes place when two 
||fl KEQUESTERS send simultaneous bus requests to a PRI ARBITER on different bus 
^m request lines. When the sequence begins, each of the REQUESTERS drives its 
respective bus request line low (REQUESTER A drives BRI* and REQUESTER B 
n™,?!^^*)- ^"^^ ARBITER detects BR1 * and BR2* low simultaneously, and it drives 
BG2IN low to Its own slot (slot 1). That BG2IN* signal is monitored by REQUESTER B 
(also in slot 1)yyhen REQUESTER B detects BG2IN* low, it responds by driving 
?»??J-ri°,^-r,."^°^^^^^'^ ^ *^®" releases the BR2* line and informs its own MASTER 
L^TF*^. ^^ ^^^^ ^^^ ^"""^ '^ available. When BBSY* goes low, the ARBITER drives 
BG2IN* of slot 1 high. 

nt?v.')^^,M?TfJl i. P°?ip'etes its data transfer(s), and signals that fact by driving 
DEVICE WANTS BUS false, REQUESTER B releases BBSY*, provided that its BG2IN* 
has been received high and 30 nanoseconds have elapsed since it released BR2*. 

The ARBITER interprets the release of BBSY* as a signal to arbitrate any current bus 
''?'^'^J!E*^ ^'"^® ^^''* '^ ^'^^ o^ly "^"S request being driven low, the ARBITER grants 
L^?.'^^^!?, REQUESTER A by driving BG1IN* low. REQUESTER A responds by 
dnvmg BBSY low. When MASTER A completes its data transfer(s) and signals that 
fact by driving DEVICE WANTS BUS false, REQUESTER A releases BBSY*; provided 
that its BG1IN* has been received high and 30 nanoseconds have elapsed since it 
released BRr. 

In this example, since no bus request lines are low when REQUESTER A releases 
BBSY*, the ARBITER waits until it detects a bus request. 

OBSERVATION 3.13: 

The description illustrated in Figures 3-5 and 3-6 would hold for both PRI and RRS 
ARBITERS, unless we consider an RRS ARBITER where the last active request was 
level BR2*. In this case, the ARBITER would process the BR1* request first and then 
proceed to the BR2* request. 

OBSERVATION 3.14: 

BBSY* and the bus grants are fully interlocked as shown in Figure 3-6: 

1 ) The ARBITER does not drive the bus grant high until it detects BBSY* low. 

2) The REQUESTER does not release BBSY* to high until it detects the bus grant high. 

3) The ARBITER does not drive the next bus grant low until it detects BBSY* high. 

4) The next REQUESTER does not drive BBSY* low until it detects the bus grant low. 
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Note: 



Detect 

DEVICE WANTS BUS 

false 

Release BBSY* 

(Continued on sheet 2) 

DEVICE WANTS BUS and DEVICE GRANTED BUS are on-board signals 
between the MASTER and its REQUESTER. (See Figure 3-4) 



Figure 3-5. Arbitration Flow Diagram 
Two REQUESTERS, Two Request Levels (Sheet 1 Of 2) 
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Figure 3-5. Arbitration Flow Diagram 
Two REQUESTERS, Two Request Levels (Sheet 2 Of 2) 



120 



DATA TRANSFER BUS ARBITRATION 



MASTERS 

HAS CONTROL 

0P0T8 



I lyiAsnn^ 
Ihiascomibch. 

0¥mB 



DRIVEN BY 
REQUESTERS 



BRV 



BBSY^ 



DRIVEN BY 
ARBITER 




BG1IN 



BG2IN* 



Note: In this example each REQUESTER maintains its bus request line low until it is 
granted the DTB. In some cases a REQUESTER might release its bus request 
line without receiving a bus grant (see Section 3.3.2). 



Figure 3-6. Arbitration Sequence Diagram 
Two REQUESTERS, Two Request Levels 
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3.4.2 Arbitration Of Two Bus Requests On The Same Bus Request Line 

oi^?.io"™^ ^'^ illustrate the sequence of events which takes place when an ROR 
aIS^Io^^*^ ^"^ ^" ^^° REQUESTER send simultaneous requests to a PRI 
o^^mIo °" ^ common bus request line. In this example, the ARBITER and RWD 
SiSiiio™ .^''® located on the system controller board in slot 1, with the ROR 
KEQUESTER located in slot 2. When the sequence begins, both of the REQUESTERS 
drive BR1 low simultaneously. The ARBITER then drives BG1 IN* low to its own slot 

a^c:o..lol ^* BG1IN* signal is monitored by REQUESTER A (also in slot 1). When 
REQUESTER A detects BG1IN* low, it responds by driving BBSY* low. REQUESTER 
A then releases BR1 * and informs MASTER A that the DTB is available. 
OBSERVATION 3.15: 

Even though REQUESTER A releases BR1*, REQUESTER B continues to drive it low 
(see Figures 3-7 and 3-8). 

After detecting BBSY* low, the ARBITER drives BG1IN* high. When MASTER A has 
D°J!\?lfl^ '*® ^^^^ transfer(s), it drives DEVICE WANTS BUS false. When 
. il^f ^^^'^ ^ detects this, and when the 30 nanoseaconds delay since the release 
of BR1 * has been satisfied, REQUESTER A releases BBSY*. 

The ARBITER interprets the release of BBSY* as a signal to arbitrate any current bus 
requests. Since the BR1 * line is still low, the ARBITER drives BG1 IN* low again When 
REQUESTER A detects BG1 IN* low, it drives its BG10UT* low because it does not 
need the DTB. REQUESTER B then detects the low on its BG1IN* and responds by 
dnving BBSY* low. When the ARBITER detects the low on BBSY*, it drives BG1IN* 
high, which causes REQUESTER A to drive its BG1 OUT* high. 

Some time later, when MASTER B has finished its data transfers, it drives DEVICE 
WANTS BUS false, indicating that it has finished using the DTB. 

Since REQUESTER B is an ROR REQUESTER, it does not release BBSY*, but keeps 
It driven low. In the event that MASTER B needs to use the DTB again, no arbitration 
will be required. In this example, however, REQUESTER A drives BR1* low, indicating 
a need to use the DTB, and REQUESTER B (which is monitoring the bus request lines) 
releases the BBSY* line. The ARBITER then grants the DTB to REQUESTER A 
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(Continued on sheet 2) 



Note- DEVICE WANTS BUS and DEVICE GRANTED BUS are on-board signals 
between the MASTER and its REQUESTER. (See Figure 3-4) 

Figure 3-7. Arbitration Flow Diagram 
Two REQUESTERS, Sanne Request Level (Sheet 1 Of 3) 
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(Continued on sheet 3) 



Figure 3-7. Arbitration Flow Diagram 
Two REQUESTERS, Same Request Level (Sheet 2 Of 3) 
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Figure 3-7. Arbitration Flow Diagram 
Two REQUESTERS, Same Request Level ( Sheet 3 of 3 ) 
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3.5 RACE CONDITIONS BETWEEN MASTER REQUESTS AND ARBITER 
GRANTS 

Suppose that there are two REQUESTERS: REQUESTER A and REQUESTER B that 
share a common bus request line. REQUESTER B, which is farther down the d'aisv- 
ciiain requests the bus and the ARBITER drives the corresponding bus grant line low 

hn!f ,f Epn, ,1:'Sxlo^*A^^°.^^^"^^'^ ^ j"^* ^^ "FASTER A signals that it wants the 
bus. I REQUESTER A is improperly designed, this situation might cause it to 
tTa°n'SfeT^ '^^ BGxOUTMine low and then high again resulting in a low-going 



3 RULE 3.13: 



REQUESTERS MUST be designed to ensure that no momentary low-goinq transients 
are generated on their BGxOUT* out line. 

OBSERVATION 3.16: 

ILl^f.-^rF^H^^^^'^ '^ designed such that it latches the state of the on-board DEVICE 
WANTS BUS line upon the falling edge of its bus grant in line, and if that signal is in 
transition when the falling edge occurs, the outputs of the latch will sometimes 
oscillate, or remain in the threshold region between the high and low levels for a short 
Dco. il:®c?™®. °^ *'^'^' ^^^ VMEbus specification does not set a time limit for the 
KhUUESTER to pass along the bus grant. It only prohibits the REQUESTER from 
generating a low-going transient on its BGxOUT* line which might be interpreted as a 
bus grant by a REQUESTER further down the daisy-chain. 

PERMISSION 3.8: 

IF a REQUESTER detects that its on-board MASTER needs the bus between the 

time that it receives a bus grant intended for another REQUESTER and the 
time it would pass that bus grant on, 

THEN it MAY treat the bus grant as its own. In this case the other REQUESTER will 
maintain its bus reqyest until another bus grant is issued. 
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Note: In this example each REQUESTER maintains its bus request line low until it is 
granted the DTB. In some cases a REQUESTER might release its bus request 
line without receiving a bus grant (see Section 3.3.2). 



Figure 3-8. Arbitration Sequence Diagram 
Two REQUESTERS, Same Request Level 
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CHAPTER 4 
PRIORITY INTERRUPT BUS 



4.1 INTRODUCTION 

The VMEbus includes a Priority Interrupt Bus which provides the signal lines needed 
to generate and service interrupts. Figure 4-1 shows a typical VMEbus system. 
INTERRUPTERS use the Priority Interrupt Bus to send interrupt requests to 
INTERRUPT HANDLERS which respond to these requests. 

Any system which has interrupt capability includes software routines that are called 
interrupt service routines, and are invoked by the interrupts. Interrupt subsystems can 
be classified into two groups: 

a. Single handler systems, which have only one INTERRUPT HANDLER that 
receives and services all bus interrupts. 

b. Distributed systems, which have two or more INTERRUPT HANDLERS that 
receive and service bus interrupts. 

4.1.1 Single Handler Systems 

In a single handler system, all interrupts are received by one INTERRUPT HANDLER, 
and all interrupt service routines are executed by one processor. Figure 4-2 shows the 
interrupt structure of a single handler system. This type of architecture is well suited to 
machine or process control applications, where a supervisory processor co-ordinates 
the activities of dedicated processors. The dedicated processors are typically 
interfaced to the machine or the process being controlled. 

The supervisory processor is the destination for all bus interrupts, servicing them in a 
prioritized manner. The dedicated processors are not required to service interrupts 
from the bus, and can give primary attention to controlling a machine or process. 

4.1.2 Distributed Systems 

Figure 4-3 shows the interrupt structure of a distributed system. This system includes 
two or more INTERRUPT HANDLERS, each servicing only a subset of the bus 
interrupts. In a typical implementation, each of the INTERRUPT HANDLERS resides^ 
on a different processor board. This type of architecture is well suited to distributed 
computing applications, where multiple, co-equal processors execute the application 
software. As each of the co-equal processors executes part of the system software, it 
might need to communicate with the other processors. In the distributed system, each 
processor services only those interrupts directed to it, establishing dedicated 
communication paths among all processors. 
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Figure 4-1 . Priority interrupt Bus Functional Blocl< Diagram 
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Figure 4-2. Interrupt Subsystem Structure: Single Handler System 
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Figure 4-3. Interrupt Subsystem Structure: Distributed System 

4.2 PRIORITY INTERRUPT BUS LINES 

The Data Transfer Bus, the Arbitration Bus, and the Priority Interrupt Bus are all used in 
the process of generating and handling bus intermpts. 

The following discussion of the Priority Interrupt Bus assumes that the reader 
understands the operation of the Data Transfer Bus described in Chapter 2, and the 
Arbitration Bus described in Chapter 3. 
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The Priority Interrupt Bus consists of seven interrupt request signal lines, one interrupt 
acknowledge line, and one interrupt acknowledge daisy-chain: 

IRQ1 * Interrupt Request 1 

IRQ2* Interrupt Request 2 

IRQ3* Interrupt Request 3 

IRQ4* Interrupt Request 4 

IRQ5* Interrupt Request 5 

IRQ6* Interrupt Request 6 

IRQ7* Interrupt Request 7 

lACK* Interrupt Acknowledge 

lACKINVIACKOUT* Interrupt Acknowledge Daisy-Chain 

4.2.1 Interrupt Request Lines 

INTERRUPTERS request interrupts by driving an interrupt request line low. In a single 
handler system, these interrupt request lines are prioritized, with IRQ7* having the 
highest priority. 

4.2.2 Interrupt Acknowledge Line 

The lACK* line runs the full length of the backplane and is connected to the lACKIN* 
pin of slot 1 (see Figure 4-4). When driven low, the lACKIN* pin causes the lACK 
DAISY-CHAIN DRIVER, located in slot 1, to propagate a falling edge down the 
interrupt acknowledge daisy-chain. 

4.2.3 Interrupt Acknowledge Daisy-Chain - lACKINVIACKOUT* 

Each of the seven interrupt request lines can be shared by two or more INTERRUPTER 
modules. The interrupt acknowledge daisy-chain assures that only one 
INTERRUPTER responds to the interrupt acknowledge cycle. This daisy-chain line 
passes through each board on the VMEbus. Each INTERRUPTER that is driving an 
interrupt request line low waits for a falling edge to arrive at its lACKIN* daisy-chain 
input. Only upon receiving this falling edge does an INTERRUPTER respond to an 
interrupt acknowledge cycle. It does not pass the falling edge on down the daisy- 
chain, preventing other INTERRUPTERS from responding to the interrupt 
acknowledge cycle. 

RULE 4.1: 

IF a VMEbus backplane slot is not occupied by a board, and if there are boards 

farther down the interrupt acknowledge daisy-chain, 
THEN jumpers MUST be installed at the empty slot to pass through the daisy-chain 

signal. 
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Figure 4-4. lACKINVIAGKOUT* DAISY-CHAIN 



4.3 PRIORITY INTERRUPT BUS MODULES - BASIC DESCRIPTION 

There are three types of functional modules associated with the Priority Interrupt Bus: 
INTERRUPTERS, INTERRUPT HANDLERS, and lACK DAISY-CHAIN DRIVERS. The 
capabilities of INTERRUPT HANDLERS and INTERRUPTERS are described by a list 
of mnemonics that show what interrupt acknowledge cycle types they can generate 
and accept, respectively. 
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Sections 4.3.1 through 4.3.3 provide block diagrams for the three types of Priority 
Interrupt Bus modules: INTERRUPT HANDLER, INTERRUPTER, and lACK DAISY- 
CHAIN DRIVER. 

RULE 4.2: 

Output signal lines shown with solid lines in Figures 4-5 through 4-7 MUST be driven 
by the module, unless it would always drive them high. 

OBSERVATION 4.1: 

IF an output line is not driven, 

THEN terminators on the backplane ensure that it is high. 

RULE 4.3: 

Input signal lines shown with solid lines in Figures 4-5 through 4-7 MUST be 
monitored and responded to in the appropriate fashion. 

OBSERVATION 4.2: 

RULES and PERMISSIONS for driving and monitoring signal lines shown with dotted 
lines in Figures 4-5 and 4-6, are given in Tables 4-1 and 4-2. 

4.3.1 INTERRUPT HANDLER 

The INTERRUPT HANDLER is used to accomplish several tasks: 

a. It prioritizes the incoming interrupt requests within its assigned group of 
interrupt request lines (highest of IRQ1*-IRQ7*). 

b. It uses its on-board REQUESTER to request the DTB and, when granted use 
of the DTB, initiates an interrupt acknowledge cycle, reading a STATUS/ID 
from the INTERRUPTER being acknowledged. 

c. It initiates the appropriate interrupt servicing sequence, based on the 
information received in the STATUS/ID. 

OBSERVATION 4.3: 

The VMEbus specification does not dictate what will happen during the interrupt 
servicing sequence. Servicing of the interrupt might or might not involve use of the 
VMEbus. 

The INTERRUPT HANDLER uses the DTB to read a STATUS/ID from the 
INTERRUPTER. In this respect, the INTERRUPT HANDLER acts like a MASTER and 
the INTERRUPTER acts like a SLAVE. However, there are four important differences. 
The INTERRUPT HANDLER: 

a. always drives lACK* low. 

b. is not required to drive the address modifier lines. 

c. only uses the lowest three address lines (A01-A03). 

d. never drives the data bus. 
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The INTERRUPT HANDLER always drives lACK* low when it accesses the bus. The 
MASTER either drives it high or does not drive it at all. 

The INTERRUPT HANDLER does not have to drive the address modifier lines with a 
valid code, and it only drives the lowest three address lines (A01-A03) with valid 
information. The levels of these three address lines indicate which of the seven 
interrupt request lines is being acknowledged, as shown in Table 4-7. A MASTER 
drives 15, 23, or 31 address lines (depending on the addressing mode) with the 
address of the SLAVE being accessed, and provides an address modifier code on the 
address modifier lines. 

The INTERRUPT HANDLER does not drive the data lines (i.e., it does not "write" to the 
INTERRUPTER) and does not have to drive the WRITE* line. A MASTER uses the data 
lines to a SLAVE bidirectionally and, during normal use, drives WRITE* low or high as 
required. 

A block diagram of the INTERRUPT HANDLER is shown in Figure 4-5. 
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The RULES and PERMISSIONS for monitoring and driving the dotted lines are 
given in Table 4-1. 



Figure 4-5. Block Diagram: INTERRUPT HANDLER 
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Table 4-1 . RULES And PERMISSIONS That Specify The Use Of The Dotted Lines 
In Figure 4-5 By The Various Types Of INTERRUPT HANDLERS 



Type of 
INTERRUPT 
HANDLER 


Use of dotted lines 


D08(O) 


MUST monitor D00-D07. 

MAY or MAY not drive LWORD* and DS1 *. 
MAY or MAY not monitor D08-D31 . 


D16 


MUST drive DSr. 
MUST monitor D00-D1 5. 

MAY or MAY not drive LWORD*. 
MAY or MAY not monitor D16-D31. 


D32 


MUST drive DS1 * and LWORD*. 
MUST monitor D00-D31 . 


ALL 


MUST not drive WRITE* low. 



I 



Note: The mnemonics D08(O), D16, and D32 are defined in Table 4-5. 



4.3.2 INTERRUPTER 



The INTERRUPTER functions as follows: 

a. It requests an interrupt from the INTERRUPT HANDLER which monitors its 
interrupt request line. 



b. IF 



THEN 
IF 



it receives a falling edge on the interrupt acknowledge daisy-chain 
input, 



it is requesting an interrupt and the levels on the three valid address 
lines correspond to the interrupt request line it is using, 
and the width of the requested STATUS/ID is either equal to, or 
greater than the size it can supply, 

THEN it supplies a STATUS/ID, 

ELSE it passes the falling edge down the interrupt acknowledge daisy- 
chain. 
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Each INTERRUPTER module drives only one interrupt request line. The VMEbus 
specification describes a board that generates interrupt requests on several interruot 
lines as having several INTERRUPTER modules. 

PERMISSION 4.1: 

Since the INTERRUPTER is just a conceptual model, logic on a VMEbus board MAY 
be shared between several INTERRUPTER modules. 

The INTERRUPTER uses one of seven lines to request an interrupt. It then monitors 
the lowest three lines of the address bus (A01-A03), the lAGKINVIAGKOUT* daisy- 
chain, and optionally lACK*, to determine when its interrupt is being acknowledged 

SIoomo"t-°oI®kW'J*uP'^°®^ '*®^"^A^^S/'^ o^^f^e data bus and signals the 
INTERRUPT HANDLER that the STATUS/ID is valid by driving DTACK* low. 

There are five primary differences in the use of the DTB by the INTERRUPTER and the 
SLAVE. The INTERRUPTER: 

a. only responds when its lACKIN* is low. 

b. does not have to monitor the address modifier lines. 

c. only monitors the lowest three address lines. 

d. does not monitor the WRITE* line. 

e. is permitted to respond with data of a different size than that 
requested. 

'^^L^}^'^^ monitors AS*, and interprets a falling edge on AS* as the signal that a 
valid bus cycle is in progress. It then proceeds to decode the appropriate number of 
address lines (15, 23, or 31), and the address modifier lines, and based on this 
information it determines whether it was addressed. However, the SLAVE responds 
only if JACK* is high. 

The INTERRUPTER, on the other hand, interprets the falling edge on its lACKIN* line 
as a signal that it can respond to the interrupt acknowledge cycle in progress It 
decodes only the lowest three address lines (A01-A03), ignoring the address modifier 
lines. 

The INTERRUPTER does not need to monitor WRITE*, since it is never written to 
SLAVES need to monitor WRITE* so that they can distinguish read cycles from write 
cycles. 

The INTERRUPTER places a STATUS/ID on the bus, and responds with DTACK* 
even if the LWORD*, DS1*, and DSO* lines call for a STATUS/ID whose width is 
greater than the INTERRUPTER is able to provide. For example, the INTERRUPT 
HANDLER might drive LWORD* and both data strobes low, indicating that it will read 
32-bits of STATUS/ID from D00-D31, but a D08(O) INTERRUPTER would still respond 
with Its 8-bit STATUS/ID on D00-D07. In contrast, when a SLAVE cannot provide the 
requested data width, it either responds with BERR* or does not respond at all 
typically resulting in a bus time-out. 
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OBSERVATION 4.4: 

When an INTERRUPTER places a STATUS/ID on the data bus, any undriven data 
lines are read by the INTERRUPT HANDLER as high because of the bus terminators. 
For example, if a D16 INTERRUPT HANDLER initiates a double byte interrupt 
acknowledge cycle, a D08(O) INTERRUPTER would place an 8-bit STATUS/ID on 
D00-D07. The upper 8 bits, read by the INTERRUPT HANDLER from D08-D15, are 
read as ones (high), since they are not driven by the D08(O) INTERRUPTER. 

RULE 4.4: 

Before responding to an interrupt acknowledge cycle, the INTERRUPTER: 

1. MUST have an interrupt request pending. 

2. The level of that request MUST match the level indicated on A01-A03. 

3. The width of the requested STATUS/ID MUST be equal to or greater than 
the size it can respond with. 

4. It MUST have received an incoming falling edge on its lACKIN* daisy-chain 
input. 

IF any of these four conditions are not met, 

THEN the INTERRUPTER MUST NOT respond to the interrupt acknowledge cycle. 
IF condition 4 is met, but either 1 , 2, or 3 is not, 

THEN the INTERRUPTER MUST pass the falling edge of lACKIN* to the next 
INTERRUPTER module in the daisy-chain. 

A block diagram of the INTERRUPTER is shown in Figure 4-6. 
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Notes: 



1. The RULES and PERMISSIONS for driving and monitoring the dotted lines 
are given in Table 4-2. 

2. This input signal is present on RORA INTERRUPTERS only 



Figure 4-6. Block Diagram: INTERRUPTER 
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Table 4-2. RULES And PERMISSIONS That Specify The Use Of The Dotted 
Lines In Figure 4-6 By The Various Types Of INTERRUPTERS 



Type of 
INTERRUPTER 


Use of dotted lines 


D08(O) 


MUST drive D00-D07. 

MUST NOT drive D08-D31 low. 

has no reason to monitor LWORD* or DS1 *. 


D16 


MUST monitor DS1*. 

MUST drive D00-D1 5. 

MUST NOT drive D16-D31 low. 

has no reason to monitor LWORD*. 


D32 


MUST monitor DS1 * and LWORD*. 
MUST drive D00-D31. 


ALL 


MAY or MAY not monitor WRITE* and lACK*. 
MAY or MAY not drive BERR*. 



I 



Note: 



The mnemonics D08(O), D16, and D32 are defined in Table 4-5. 
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4.3.3 lACK DAISY-CHAIN DRIVER 



The lACK DAISY-CHAIN DRIVER is another module that interacts with INTERRUPT 
HANDLERS and INTERRUPTERS to coordinate the servicing of interrupts. It 
generates a falling edge on the interrupt acknowledge daisy-chain each time an 
INTERRUPT HANDLER initiates an interrupt acknowledge cycle. 

A block diagram of the lACK DAISY-CHAIN DRIVER is given in Figure 4-7. 
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Figure 4-7. Block Diagram: lAQK DAISY-CHAIN DRIVER 
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4.3.4 Interrupt Request Handling Capabilities 

INTERRUPT HANDLERS can be designed to handle interrupt requests received on 
one to seven interrupt request lines. Table 4-3 shows how the IH( ) mnemonic is used 
to describe the interrupt handling capabilities of INTERRUPT HANDLERS. 



Table 4-3. Use Of The IH( ) Mnemonic To Specify Interrupt 
Request Handling Capabilities 



The 
Following 
Mnemonic 


When 
Applied 
to an 


Means that it 


IH(x-y) 


INTERRUPT 
HANDLER 


can generate interrupt acknowledge 
cycles in response to interrupt requests 
on lines IRQx* through IRQy*. 


IH(x) 


INTERRUPT 
HANDLER 


can generate interrupt acknowledge cycles 
in response to interrupt requests 
on line IRQx*. 



I 



4.3.5 Interrupt Request Generation Capabilities 

INTERRUPTERS can be designed to generate an interrupt request on any of the 
seven interrupt request lines. Table 4-4 shows how the l( ) mnemonic is used to 
describe the interrupt request generation capabilities of INTERRUPTERS. 



Table 4-4. Use Of The l( ) Mnemonic To Specify Interrupt Request 
Generation Capabilities 



The 
Following 
Mnemonic 



When 
Applied 
to an 



Means that it 



l(x) 



INTERRUPTER 



can generate an interrupt request on 
line IRQx*. 
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4.3.6 STATUS/ID Transfer Capabilities 

There are three STATUS/ID transfer capabilities: D08(O), D16 and D32. Table 4-5 
shows how these mnemonics are used to describe the interrupt handling capabilities 
of INTERRUPT HANDLERS and INTERRUPTERS. 



Table 4-5. Mnemonics That Specify STATUS/ID Transfer Capabilities 



I 



The 
Following 
Mnemonic 



When 
Applied 
to an 



D08(O) 



INTERRUPTER 



INTERRUPT 
HANDLER 



D16 



INTERRUPTER 



INTERRUPT 
HANDLER 



D32 



INTERRUPTER 



INTERRUPT 
HANDLER 



Means that it 



responds to 8-bit, 16-bit, and 32-bit 
interrupt acknowledge cycles by providing 
an 8-bit STATUS/ID on D00-D07. 

generates 8-bit interrupt acknowledge 
cycles in response to the requests on the 
interrupt request line(s) and reads an 
8-bit STATUS/ID from D00-D07. 



responds to 16-bit and 32-bit interrupt 
acknowledge cycles by providing a 16-bit 
STATUS/ID on D00-D1 5 

generates 16-bit interrupt acknowledge 
cycles in response to the requests on the 
interrupt request line(s) and reads a 
16-bit STATUS/ID from D00-D15. 



responds to 32-bit interrupt acknowledge 
cycles by providing a 32 bit STATUS/ID on 
D00-D31. 

generates 32-bit interrupt acknowledge 
cycles in response to the requests on the 
interrupt request line(s) and reads a 
32-bit STATUS/ID from D00-D31 . 
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4.3.7 Interrupt Request Release Capabilities 

Many widely used peripheral ICs generate interrupt requests. Unfortunately, tiiere is 
no standard method for indicating to these ICs when it is time for them to remove their 
interrupt request from the bus. Three methods are used: 

a. When the relevant processor senses an interrupt request from a peripheral 
device, it enters an interrupt service routine, and READS a status register in 
the device. The peripheral device interprets this read cycle on its status 
register as a signal to remove its interrupt request. 

b. When the relevant processor senses an interrupt request from a peripheral 
device, it enters an interrupt service routine, and WRITES to a control 
register in the device. The peripheral device interprets this write cycle to its 
control register as a signal to remove its interrupt request. 

0. When the relevant processor senses an interrupt request from a peripheral 
device, it reads a STATUS/ID from the device. The peripheral device 
interprets this read cycle as a signal to remove its interrupt request. 

The VMEbus specification calls INTERRUPTERS that use methods a and b Release 
On Register Access (RORA) INTERRUPTERS, and those that use method c Release 
On AcKnowledge (ROAK) INTERRUPTERS. Figure 4-8 shows how an ROAK 
INTERRUPTER releases its interrupt request line when the INTERRUPT HANDLER 
reads its STATUS/ID and how an RORA INTERRUPTER releases its interrupt request 
upon an access to a control or status register. 

OBSERVATION 4.5: 

The SLAVE that provided the access to the INTERRUPTER'S control or status register 
is typically on the same board as the INTERRUPTER, and it generates an on-board 
signal to the INTERRUPTER when it has completed the register access. 

RULE 4.5: 

An RORA INTERRUPTER MUST NOT release its interrupt request line before it 
detects a falling edge on DSA* during the register access cycle. It MUST release the 
interrupt request line within 2 microseconds after the last data strobe goes high at the 
end of the register access cycle. 

RULE 4.6: 

An ROAK INTERRUPTER MUST NOT release its interrupt request line before it 
detects a falling edge on DSA* during the interrupt acknowledge cycle which 
acknowledges its interrupt, and it MUST release its interrupt request line within 500 
nanoseconds after the last data strobe goes high at the end of the STATUS/ID read 
cycle. 

RULE 4.7: 

Both RORA and ROAK INTERRUPTERS MUST provide a STATUS/ID during the 
interrupt acknowledge cycle that was initiated in response to their interrupt request. 
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RULE 4.8: 

After an INTERRUPT HANDLER initiates an interrupt acknowledge cycle and reads the 
STATUS/ID from an RORA INTERRUPTER, it MUST ignore the low level on the 
interrupt request line for 2 microseconds after its on-board signal REGISTER 
ACCESSED goes true. 

OBSERVATION 4.6: 

RULE 4.8 prevents the INTERRUPT HANDLER from misinterpreting the low level on 
that line as anew interrupt request. 

OBSERVATION 4.7: 

The MASTER that accesses the INTERRUPTER'S control or status register is typically 
on the same board as the INTERRUPT HANDLER, and it generates an on-board 
signal to the INTERRUPT HANDLER when it has completed the register access. 

PERMISSION 4.2: 

IF a procedure is established to allow the MASTER to signal the INTERRUPT 

HANDLER that an access to the INTERRUPTER'S control or status registers 
has taken place 

THEN the MASTER and INTERRUPT HANDLER MAY reside on different boards. 



Table 4-6 shows how the RORA and ROAK mnemonics are used to describe 
INTERRUPTERS. 



- PHASE 1 
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Figure 4-8. Release Of Interrupt Request Lines By ROAK And RORA INTERRUPTERS 
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Table 4-6. Mnemonics That Specify Interrupt Request Release Capabilities 



The 
Following 
Mnemonic 


When 

Applied 

to a 


Means that it 


RORA 


INTERRUPTER 


releases its interrupt request line wlien 
some MAS 1 bR accesses an on-board 
status or control register. 


ROAK 


INTERRUPTER 


releases its interrupt request line when 
its STATUS/ID is read during an interrupt 
acknowledge cycle. 



B 



4.3.8 Interaction Between Priority Interrupt Bus Modules 

In the following discussions, several on-board signals are defined to describe the 
interaction between the INTERRUPTER and INTERRUPT HANDLER modules and 
other on-board logic. These signals are only intended to illustrate the information 
which is passed to and from the modules, rather than to define their designs. 

PERMISSION 4. 3: 

VMEbus boards MAY be designed with on-board signals that differ from those used in 
the following discussions. 

Figure 4-4 shows how the lACKINVIACKOUT* daisy-chain is routed through a typical 
configuration of boards on the VMEbus. 

The lACK* line runs the full length of the backplane and can be driven by any 
INTERRUPT HANDLER that has control of the DTB. The backplane connects lACK* to 
the lACKIN* pin of slot 1. The lACK DAISY-CHAIN DRIVER resides in slot 1 and 
monitors the level of slot 1's lACKIN* line. 

When an INTERRUPT HANDLER drives lACK* (and slot Vs lACKIN*) low, and then 
drives DSA* low, the lACK DAISY-CHAIN DRIVER generates a falling edge on its 
lACKOUT* pin. This pin is connected to the lACKIN* pin of s^ot 2. A jumper on the 
board in slot 2 routes the falling edge on the lACKIN* pin to the lACKOUT* pin, and 
through the backplane to the lACKIN* pin of the board in slot 3. The INTERRUPTER in 
slot 3 does not have a pending interrupt request, so it passes on the falling edge to its 
lACKOUT* pin. The INTERRUPTER in slot 4 then detects the falling edge on its 
lACKIN* line and responds by placing its STATUS/ID on the data bus, and then driving 
DTACK*low. 
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PERMISSION 4.4: 

An INTERRUPTER MAY reside on the system controller board, installed in slot 1, 
along with the lACK DAISY-CHAIN DRIVER. Figure 4-9 shows how the two modules 
would be connected. 

PERMISSION 4.5: 

More than one INTERRUPTER MAY reside on a board. Figure 4-10 shows how this 
might be done. 

OBSERVATION 4.8: 

In some cases, board designers might not know whether or not the board they are 
designing will be installed in slot 1 , or in some other slot of a VMEbus system. 

a RECOMMENDATION 4.1: 
IF a board includes both an lACK DAISY-CHAIN DRIVER and an 

INTERRUPTER, and might or might not be installed in slot 1 , 
THEN design it as shown in Figure 4-9. 

PERMISSION 4.6: 

Several boards containing lACK DAISY-CHAIN DRIVERS MAY be installed in a 
VMEbus system. 
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Figure 4-9. An lACK DAISY-CHAIN DRIVER And INTERRUPTER On The Same Board 
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Figure 4-10. Two INTERRUPTERS On The Same Board 
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4.4 TYPICAL OPERATION 

A typical interrupt sequence can be divided into tiiree phases: 

Phase 1 : The interrupt request phase. 
Phase 2: The interrupt acknowledge phase. 
Phase 3: The interrupt servicing phase. 

Figure 4-1 1 illustrates the timing relationships between the three phases. 

Phase 1 starts when an INTERRUPTER drives an interrupt request line low and ends 
when the INTERRUPT HANDLER gains control of the DTB. During phase 2 the 
INTERRUPT HANDLER uses the DTB to read the INTERRUPTER'S STATUS/ID 
Dunng phase 3 an interrupt servicing routine is executed. (This might or miqht not 
involve data transfers on the VMEbus.) 

The protocol for the interrupt subsystem describes the module interaction required 
dunng phase 1 and phase 2. Any data transfers which take place during phase 3 will 
follow the Data Transfer Bus protocol described in Chapter 2. 





INTERRUPT 


INTERRUPT 


IRQX* 


HANDLER 


HANDLER 


DRIVEN 


GAINS CONTROL 


FINISHES READING 


LOW 


OF THE DTB 


INTERRUPTERS 



INTERRUPT 
REQUEST 
(PHASE 1) 



INTERRUPT 

ACKNOWLEDGE 

(PHASE 2) 



INTERRUPT 
SERVICING 
(PHASE 3) 



Figure 4-1 1 . The Three Phases Of An Interrupt Sequence 
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4.4.1 Single Handler Interrupt Operation 



In single handler interrupt systems, the seven interrupt request lines are all monitored 
by a single INTERRUPT HANDLER. The interrupt request lines are prioritized such 
that IRQ7* has the highest priority, and IRQ1* has the lowest priority. When the 
INTERRUPT HANDLER detects simultaneous requests on two interrupt request lines, it 
acknowledges the highest priority request first. 

4.4.2 Distributed Interrupt Operation 

Distributed interrupt systems contain from two to seven INTERRUPT HANDLERS. For 
purposes of the following discussion, distributed interrupt systems will be considered 
in two groups: 

a. distributed interrupt systems with seven INTERRUPT HANDLERS, 

b. distributed interrupt systems with two to six INTERRUPT HANDLERS. 

4.4.2.1 Distributed Interrupt Systems With Seven INTERRUPT 
HANDLERS 

In distributed interrupt systems with seven INTERRUPT HANDLERS, each of the 
interrupt request lines is monitored by a separate INTERRUPT HANDLER. Each 
INTERRUPT HANDLER gains control of the DTB before it reads the STATUS/ID from 
INTERRUPTERS driving its interrupt request line. 

OBSERVATION 4.9: 

There is no specified relationship between the interrupt request line that an 
INTERRUPT HANDLER services and the bus request line used by its on-board 
REQUESTER. For example, an INTERRUPT HANDLER that services IRQ7* might 
have a REQUESTER that uses BRO*, and an INTERRUPT HANDLER that services 
IRQ1* might have a REQUESTER that uses BR3*. It is clear from this that there is no 
implied interrupt priority between lines serviced by different INTERRUPT HANDLERS. 

Figure 4-12 illustrates a distributed interrupt system where INTERRUPT HANDLER A 
monitors IRQ2* and has an on-board REQUESTER which requests the DTB on BR2*. 
INTERRUPT HANDLER B monitors IRQ5* and has an on-board REQUESTER which 
requests the DTB on BR3*. Two INTERRUPTERS simultaneously drive IRQ2* and 
IRQ5* low, and the two INTERRUPT HANDLERS cause their on-board REQUESTERS 
to drive BR2* and BR3* low simultaneously. In this example, priority arbitration is used 
and, since both bus requests go low together, the ARBITER first grants control of the 
DTB to INTERRUPT HANDLER B's REQUESTER, and INTERRUPT HANDLER A waits 
until B has finished using the DTB. 

OBSERVATION 4.10: 

If round-robin arbitration is used, either of the INTERRUPT HANDLERS described in 
Figure 4-12 might be granted the bus first. 
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PC BOARD #1 



PC BOARD #2 



I 




Figure 4-12. Two INTERRUPT HANDLERS, Each Monitoring One Interrupt 
Request Line 



4.4.2.2 Distributed Interrupt Systems With Two To Six INTERRUPT 
HANDLERS 

it is also possible to configure a distributed interrupt system in which two or more of the 
interrupt request lines are monitored by a single INTERRUPT HANDLER. Figure 4-13 
illustrates a system configured with two INTERRUPT HANDLERS in which 
INTERRUPT HANDLER A monitors IRQ1*-IRQ4*, and INTERRUPT HANDLER B 
monitors IRQ5*-IRQ7*. In this case, the IRQ1*-IRQ4* lines are prioritized; IRQ4* = 
highest priority for INTERRUPT HANDLER A, and the IRQ5*-IRQ7* lines are prioritized- 
IRQ7* = highest priority for INTERRUPT HANDLER B. The DTB arbitration still 
determines which INTERRUPT HANDLER is granted the use of the DTB first. 
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Figure 4-13. Two INTERRUPT HANDLERS, Each Monitoring Several Interrupt 
Request Lines 
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4.4.3 Example: Typical Single Handler Interrupt System Operation 

Figure 4-14 illustrates the operation of a single handler interrupt system in which one 
INTERRUPT HANDLER monitors and prioritizes all seven interrupt lines. At the top of 
the diagram, a MASTER is using the DTB to move data within the system at a bus 
request level of 2. An INTERRUPTER in slot 3 requests an interrupt by driving IRQ4* 
low. When the INTERRUPT HANDLER detects the low level on IRQ4* it sends a signal 
to Its on-board REQUESTER, indicating that it needs the bus. This REQUESTER then 
dnves BR3* low. Upon detecting the bus request, the ARBITER drives BCLR* low 
indicating that a higher priority REQUESTER is waiting for the DTB. (This example 
assumes a PRI ARBITER). When MASTER A detects the low level on BCLR*, it stops 
moving data and allows its requester to relinquish control of the DTB, and release 
BBSY*. 

I OBSERVATION 4.11: 
The active MASTER is not required to relinquish the DTB within any specified time but 
a prompt response to the BCLR* line allows the interrupt to be serviced quicker. 

When the ARBITER detects BBSY* high, it grants the DTB to REQUESTER B, which 
informs its INTERRUPT HANDLER that the DTB is available (see Figures 2-26 and 2- 
27). The INTERRUPT HANDLER then puts out a 3-bit code on the lower three address 
lines, indicating that it is acknowledging the interrupt request on the IRQ4* line (see 
Table 4-7). At the same time, it drives lACK* low, indicating that it is acknowledging an 
interrupt, and drives AS* low. The low level on lACK* is connected, by a signal trace 
in the backplane, to the lACKIN* pin of slot 1 and causes the lACK DAISY-CHAIN 
DRIVER to generate a falling edge down the IACKIN*/IACKOUT* daisy-chain. 

When the INTERRUPTER detects a falling edge on its incoming daisy-chain line 
(lACKIN*) it checks the lower three address bits to see if they match the interrupt 
request line which it is driving low. Since the 3-bit code matches the line on which it is 
making its interrupt request, when the INTERRUPTER detects the data strobe(s) low it 
places Its STATUS/ID on the data bus and drives the DTACK* line low. When the 
INTERRUPT HANDLER detects the low DTACK*, it reads the STATUS/ID and 
activates the appropriate interrupt service routine. 
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(Continued on sheet 2) 



Figure 4-14. Typical Single Handler Interrupt System Operation 
Flow Diagram (Sheet 1 Of 2) 
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Figure 4-14. Typical Single Handler Interrupt System Operation 
Flow Diagram (Sheet 2 Of 2) 
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Table 4-7. 3-Bit Interrupt Acknowledge Code 



Interrupt line 
being acknowledged 



Use of the address bus to broadcast 
the 3-bit Interrupt acknowledge code 



A03 



A02 



A01 



iRor 

IRQ2* 
IRQ3* 
IRQ4* 
IRQ5* 
IRQ6* 
IRQ7* 



L 

L 
L 
H 
H 
H 
H 



L 
H 
H 
L 
L 
H 
H 



H 
L 
H 

L 
H 

L 
H 



I 



H = High level 
L = Low level 



4.4.4 Example: Prioritization Of Two Interrupts In A Distributed Interrupt 
System 

Figure 4-15 illustrates the operation of a distributed interrupt system with two 
INTERRUPT HANDLERS. INTERRUPT HANDLER A monitors lRQr-IRQ4*, while 
INTERRUPT HANDLER B monitors IRQ5*-IRQ7*. INTERRUPT HANDLER A treats 
iRQ4* as its highest priority interrupt, while INTERRUPT HANDLER B treats IRQ7* as 
its highest priority interrupt. At the top of the diagram, INTERRUPTER C dnves IRQ3* 
low, and INTERRUPTER D drives IRQ6* low. Both INTERRUPT HANDLERS detect 
their respective interrupt request pnes low, and both simultaneously indicate to their 
on-board REQUESTER that they need the DTB. Both the REQUESTERS drive BR3* 
low Upon detecting BR3* low, the DTB ARBITER drives BG3IN* low on slot 1. This 
low signal is passed down the BG3INVBG30UT* daisy-chain until it is detected by the 
REQUESTER B in slot 4. This REQUESTER then signals its on-board INTERRUPT 
HANDLER B that the DTB is available. INTERRUPT HANDLER B then reads the 
STATUS/ID from INTERRUPTER D. 
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Figure 4-15. Typical Distributed Interrupt System With Two INTERRUPT HANDLERS 
Flow Diagram 
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4.5 PRIORITY INTERRUPT BUS TIMING RULES AND OBSERVATIONS 

This section describes the timing RULES and OBSERVATIONS that govern the 
behavior of INTERRUPT HANDLERS, INTERRUPTERS, and lACK DAISY-CHAIN 
DRIVERS during the selection of the responding INTERRUPTER (i.e. the 
INTERRUPTER that is to provide its STATUS/ID in response to the interrupt 
acknowledge cycle). This timing information is in the form of Figures and Tables. 

The interrupt acknowledge cycle begins with the selection of the responding 
INTERRUPTER. This is called the INTERRUPTER selection portion of the cycle. Once 
an INTERRUPTER responds, the INTERRUPT HANDLER reads the STATUS/ID from it. 
This is called the STATUS/ID transfer portion of the cycle. 

When the INTERRUPT HANDLER initiates an interrupt acknowledge cycle, there might 
be INTERRUPTERS between it and the INTERRUPTER being acknowledged that 
either: 

a. do not have an interrupt pending, 

b. have an interrupt pending, or on a different interrupt request line than the 
one being acknowledged. 

Although these INTERRUPTERS do not respond with a STATUS/ID, they do 
participate in the interrupt acknowledge cycle by passing the falling edge from their 
lAGKIN* line on to their lAGKOUT* line. For this reason, these INTERRUPTERS are 
called participating INTERRUPTERS. 

The first INTERRUPTER in the daisy-chain that has an interrupt pending on the 
interrupt request line being acknowledged responds with a STATUS/ID. For this 
reason it is called the responding INTERRUPTER. All other INTERRUPTERS are 
called non-participating INTERRUPTERS. 

Table 4-8 lists timing Tables and timing diagrams that specify INTERRUPT 
HANDLER and INTERRUPTER operation. 

Table 4-9 lists timing Tables and timing diagrams that specify lACK DAISY-CHAIN 
DRIVER operation. 

Table 4-10 lists timing Tables and timing diagrams that specify participating 
INTERRUPTER operation. 

Table 4-11 lists timing Tables and timing diagrams that specify responding 
INTERRUPTER operation. 

Table 4-12 defines the mnemonics that are used in Tables 4-13 through 4-15. 

Tables 4-1 through 4-15 specify the use of bus signal lines by the Priority Interrupt 
Bus functional modules. 
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Ss't^fnction^J mnH.?!o/""llK^P®f y ^^® ^''^'"S parameters for the Priority Interrupt 
?o^e^pS;onh?tt!rgpi;^^^ ^a^'- ^-1^ through 4-1^9 

^nrr"?atk:o^:!lycy^^^^^^^ "^ '"'"^ ^'^^""^^ ''^' ^^^^'^^ *^^ *--9 during 
€& *"^* specifies additional inter-cycle timing for the lACKINVIACKOUT daisy- 
All of the RULES and OBSERVATIONS associated with the Figures listed below also 
DRiJJeRS ''^^^'" HANDLERS. INTERRUPTERS. and^yicK DAISY°CHAtS 

I "^^^Z%l^ela'STtr^^^^^^^ ' ^'^'^^ ''' ^'"^'"^ ^- ^^^ -^^-- -^ data 

Figure 2-25 specifies the timing of a timed-out cycle. 
Figures 2-26 and 2-27 specify the timing during mastership transfer. 
In order to meet the specified timing, board designers have to take into account thP 

Sf 'r^'^P^^^*'"" ''"'^y" °^ ^^^^^^^ drivers Ind receivers utd on ?herr?MEbus 
boards. The propagation delay of the drivers depends on their outDuMoads 

ca7ulat'e\he"'oro?aSn If/''"^^^^ '° "°* ^'^^'^ Qive enough Sl^lTto 
calculate the propagation delays under various loads. To help the VMEbus board 
designer, some suggestions are offered in Chapter 6. vivitous ooard 

The OBSERVATIONS specify the timing of incoming lines signal transitions ThesP 

not'violSeS' ?hl'F^jLEV?or°tZ1? ^'? ^-^plane Poading RlLES^n^'Spter'JSI 
noi vioiaiea. i he RULES for the bus terminators h Chapter 6 Guarantee that thP 
timing parameters for signal lines that are released after they have ?een driven! arl 

Typically, for each timing RULE there is a corresponding timing OBSERVATION 

spTcS' KfthrRufp' ^ZT'"" '? *'' OBSERvXtIOnI might'diSom this 
speciTiea by the RULE. For example, a carefu mspection of the timina diaaram«: 
shows tha the INTERRUPT HANDLER is required to provide 35 nanosecSids of 
fs Susfth^eSrP."^ h' 'NTERRUPTER is 2 nly guaranteed 10 nanosSs ThS 
s because he address dnvers are not always able to drive the backplane's sianal 
lines completely through the low to high threshold region, until the transition 
KSf !t' *K '^t '"^ °^ '^^ ^^""^P'^"^ ^"d '^ ^^f'^^ted back. The fa ling edge Se 
S1ohL'*'°t^ h°r^^'' JyP'^^"y ^'■°^^^s *he 0.8-volt threshold without waiting or a 

NTlRmlPTl'\\?r^lp1i.i^^'■^'"'*'"^ ^"^-"P ^'"^^ ^' the INTERRUPTER is the 
INTERRUPT HANDLER'S set-up time less two bus propagation times. 

strSS mq%^*i°nH HQiM h" "^^"^ !° "^^^""^ ^^^ ^^^^ ^^'°^^ ^^^'^Q- ^he two data 
nZ^oli J?h and DS1 ) do not always make their transitions simultaneously. For 
purposes of these timing diagrams, DSA* represents the first data strobe to make its 
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transition (whether that is DSO* or DSr). DSB* represents the second data strobe to 
make its transition (whether that is DS1* or DSO*). The broken line shown while the 
data strobes are sTable indicates that the first data strobe to make a fallmg transition 
might not be the first to make its rising transition -- i.e., DSA* might represent DSO on 
its falling edge and DS1* on its rising edge. 



Table 4-8. Timing Diagrams That Define INTERRUPT HANDLER And 
INTERRUPTER Operation 



Mnemonic 



Type of cycle 



INTERRUPTER STATUS/ID 

Selection Transfer 

Timing Diag Timing Diag 

Figures Figure 



D08(O) SINGLE BYTE STATUS/ID READ 2-12 & 4-16 



D16 DOUBLE BYTE STATUS/ID READ 2-12 & 4-16 



D32 QUAD BYTE STATUS/ID READ 2-12 & 4-16 



4-20 



4-21 



4-21 



B 



Note: 



See Tables 4-16 and 4-17 for timing parameters 



Table 4-9. Timing Diagrams That Define JACK DAISY-CHAIN DRIVER Operation 



Type of cycle 



SINGLE BYTE STATUS/ID READ 



DOUBLE BYTE STATUS/ID READ 



QUAD BYTE STATUS/ID READ 



INTERRUPTER 
Selection 
Timing Diag 



Figure 4-17 



Figure 4-17 



Figure 4-17 



Note: 



See Tables 4-16 and 4-19 for timing values 
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Table 4-10. Timing Diagrams That Define Participating INTERRUPTER Operation 



B 



Type of cycle 



SINGLE BYTE STATUS/ID READ 



DOUBLE BYTE STATUS/ID READ 



QUAD BYTE STATUS/ID READ 



Note: 



INTERRUPTER 

selection 

Timing Diag 



Figure 4-1 8 



Figure 4-1.8 



Figure 4-18 



See Tables 4-16 and 4-18 for timing values 



Table 4-1 1 . Timing Diagrams That Define Responding INTERRUPTER Operation 



Mnemonic Type of cycle 



INTERRUPTER STATUS/ID 
selection Transfer 

Timing Diag Timing Diag 



Note: 



See Tables 4-16 and 4-18 for timing values 



D08(O) SINGLE BYTE STATUS/ID READ Figure 4-1 9 Figure 4-22 



E>16 DOUBLE BYTE STATUS/ID READ Figure 4-19 Figure 4-23 



D32 QUAD BYTE STATUS/ID READ Figure 4-1 9 Figure 4-23 
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Table 4-12. Definitions Of Mnemonics Used In Tables 4-13, 4-14, And 4-15 



Mnemonic Description 



DVBIH DRIVEN VALID 
BY INTERRUPT 
HANDLER 



DLBIH DRIVEN LOW 
BY INTERRUPT 
HANDLER 



DHBIH DRIVEN HIGH 
BY INTERRUPT 
HANDLER 



dhbih? DRIVEN HIGH BY 
INTERRUPT 
HANDLER? 



dxbih? 



DRIVEN BY 

INTERRUPT 

HANDLER? 



Comments 



RULE 4.9: 

INTERRUPT HANDLER MUST drive DVBIH 

lines to a valid level. 



RULE 4.10: 

INTERRUPT HANDLER MUST drive DLBIH 

lines to a low level. 



RULE 4.11: 

INTERRUPT HANDLER MUST drive DHBIH 

lines to a high level. 



PERMISSION 4.7: 

INTERRUPT HANDLER MAY drive dhbih? 

lines high. 

RULE 4.12: 

INTERRUPT HANDLER MUST NOT drive dhbih? 

lines low during the cycle. 



I 



PERMISSION 4.8: 

INTERRUPT HANDLER MAY drive dxbih? 
lines during the cycle, or it MAY leave 
dxbih? lines undriven. (When the line is 
driven it carries no valid information.) 



DVBI DRIVEN VALID 

BY INTERRUPTER 



RULE 4.13: 

INTERRUPTER MUST drive DVBI lines to a 

valid level. 



dhbi? DRIVEN BY 

INTERRUPTER? 



PERMISSION 4.9: 

INTERRUPTER MAY drive dhbi? lines high. 

RULE 4.14: 

INTERRUPTER MUST NOT drive dhbi? lines 

low. 
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Table 4-12. Definitions Of Mnemonics Used In Tables 4-13, 4-14. And 4-15 (cont'd) 



Mnemonic Description 



Comments 



dxbi? DRIVEN BY 

INTERRUPTER? 



PERMISSION 4.10: 

INTERRUPTER MAY drive dxbi? lines during tlie 
cycle, or it MAY leave the line undriven. (When 
the line is driven, itcarries no valid information.) 



I 



Table 4-13. Use Of Addressing Lines During Interrupt Acknowledge Gyles 



Interrupt Line A03 

Being Aclcnowledged 



A02 



iRor 

IRQ2* 
IRQ3* 
IRQ4* 
IRQ5* 
IRQ6* 
IRQ7* 



DLBIH 


DLBIH 


DLBIH 


DHBIH 


DLBIH 


DHBIH 


DHBIH 


DLBIH 


DHBIH 


DLBIH 


DHBIH 


DHBIH 


DHBIH 


DHBIH 



A01 


lACK* 


DHBIH 


DLBIH 


DLBIH 


DLBIH 


DHBIH 


DLBIH 


DLBIH 


DLBIH 


DHBIH 


DLBIH 


DLBIH 


DLBIH 


DHBIH 


DLBIH 



Table 4-14. Use Of The DS1*, DSO*, LWORD*, And WRITE* Lines Durina 
Interrupt Acknowledge Cycles 



Mnemonic Type of cycles DSI* DSO* LWORD* 



WRITE* 



D08(O) Single byte interrupt 

acknowledge dhbih? DLBIH dhbih? dhbih? 



D16 Double byte interrupt 

acknowledge DLBIH DLBIH dhbih? dhbih? 



D32 Quad byte intermpt 

acknowledge 



DLBIH DLBIH DLBIH dhbih? 
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Table 4-15. Use Of The Data Bus Lines To Transfer The STATUS/ID 



Mnemonic 


Type of cycles 


D24- 
D31 


Die- 
Das 


DOS- 
D15 


DOO- 
D07 


D08(O) 


Single, double, and quad 
byte intentipt acknowledge 


dhbi? 


dhbi? 


dhbi? 


DVBI 


D16 


Double and quad byte 
interrupt acknowledge 


dhbi? 


dhbi? 


DVBI 


DVBI 


D32 


Quad byte inten-upt 
acknowledge 


DVBI 


DVBI 


DVBI 


DVBI 
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Table 4-16. INTERRUPT HANDLER, INTERRUPTER, And lACK DAISY-CHAIN 
DRIVER Timing Parameters 



PARAMETER 


INTERRUPT 


INTERRUPTER 


lACK DAISY- 


NUMBER 


HANDLER 






CHAIN DRIVER 




See Table 


4-17 


See Table 


4-18 


See Table 4-19 




MIN 


MAX 


MIN 


MAX 


MIN MAX 


1 













2 













3 


60 










4 


35 




10 






5 


40 




30 




30 


6 













7 













9 














10 













11 


40 




30 






12 


35 




10 






13 




10 




20 




14 














16 














18 














19 


40 




30 




30 


20 
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Table 4-1 6. INTERRUPT HANDLER, INTERRUPTER, And lAGK DAISY-CHAIN 
DRIVER Timing Parameters (cont'd) 



PARAMETER 
NUMBER 



I 



35 

36 

37 

38A 

388 

39 

40 

41 

42 

43 



INTERRUPT 

HANDLER 

See Table 4-17 

MIN MAX 



21 





23 


10 


24A 





248 





25 




26 





27 


-25 


28 


30 


29 





30 





31 





32 




34 





25 
2T 



NOTES: 

1. Ail times are in nanoseconds. 

2. T = tiie time-out value. 



INTERRUPTER 

See Table 4-18 
MIN MAX 











30 



10 
40 






30 


30 



I ACK DAISY- 
CHAIN DRIVER 
See Table 4-19 

MIN MAX 



10 
40 



30 



40 



30 



30 
30 
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Table 4-1 7. INTERRUPT HANDLER, Timing RULES And OBSERVATIONS 
Note: The numbers correspond to tlie timing parameters specified in Table 4-16. 

1. RULE 4.15: 

Wlien taking control of the VMEbus, the INTERRUPT HANDLER MUST NOT 
drive any of lACK*, A01-A03, LWORD*. WRITE*, DSO*. DS1* or AS* until after 
the previous MASTER or INTERRUPT HANDLER allows AS* to rise above the 
low level. 

OBSERVATION 4.12: 

Chapter 3 describes how an INTERRUPT HANDLER'S REQUESTER is granted 
use of the VMEbus. 

2. RULE 4.16: 

When taking control of the VMEbus, the INTERRUPT HANDLER MUST NOT 
drive any of lACK*, A01-A03, LWORD*. WRITE*. DSO*, DS1*, or AS* until after it 
receives DEVICE GRANTED BUS taie. 

OBSERVATION 4.13: 

Chapter 3 describes how an INTERRUPT HANDLER'S REQUESTER is granted 
use of the VMEbus. 

3 RULE 4 17: 

When taking control of the VMEbus, the INTERRUPT HANDLER MUST NOT 
drive AS* low until this time after the previous MASTER or INTERRUPT 
HANDLER allows AS* to rise above the low level. 

OBSERVATION 4.14: 

RULE 4.17 ensures that timing parameter 5 for INTERRUPTERS and SLAVES 
is guaranteed when there is an interchange of the DTB mastership. 

4. RULE 4.18: 

The INTERRUPT HANDLER MUST NOT drive AS* low until lACK* has been 
low, and LWORD* and A01-A03 have been valid for this minimum time. 

5. RULE 4.19: 

When using the DTB for two consecutive cycles, the INTERRUPT HANDLER 
MUST drive AS* low until it has been high for this minimum time. 

9 RULE 4 20' 

The INTERRUPT HANDLER MUST NOT drive DSA* low until both DTACK* 

and BERR* are high. 

1 RULE 4 21 ■ 

The INTERRUPT HANDLER MUST NOT drive DSA* low before it has driven 

AS* low. 
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Table 4-1 7. INTERRUPT HANDLER, Timing RULES And OBSERVATIONS (cont'd) 

11. RULE 4.22: 

The INTERRUPT HANDLER MUST NOT drive DSA* low until DSO* and DS1* 
have been simultaneously high for this minimum time. 

12. RULE 4.23: 

The INTERRUPT HANDLER MUST NOT drive DSA* low until WRITE* has 
been high for this minimum time. 

13. RULE 4.24: 

EaSi cd^mmo-^*! °'' ?!i?^.'^y*® STATUS/ID read cycles, the INTERRUPT 
HANDLER MUST dnve DSB* low within this maximum time after it drives DSA* 
low. 

OBSERVATION 4.15: 

Timing parameter 1 3 does not apply to single byte STATUS/ID reads. 

14. RULE 4.25: 

During all interrupt acknowledge cycles, the INTERRUPT HANDLER MUST 
hold the 3 bit interrupt acknowledge code valid, and maintain the appropriate 
level on LWORD* until it detects a falling edge on DTACK* or BERR*. 

16. RULE 4.26: 

During all interrupt acknowledge cycles, the INTERRUPT HANDLER MUST 
maintain lACK* low until it detects a falling edge on DTACK* or BERR*. 

18. RULE 4.27: 

Soll:'!^^^^^'^ HANDLER MUST hold AS* low until it detects DTACK* or 
BERR low. 

19. RULE 4.28: 

The INTERRUPT HANDLER MUST hold AS* low for this minimum time. 

20. RULE 4.29: 

Once an INTERRUPT HANDLER has driven DSA* low, it MUST maintain it low 
until it detects DTACK* or BERR* low. 

21. RULE 4.30: 

Once an INTERRUPT HANDLER has driven DSB* low, it MUST maintain it low 
until It detects DTACK* or BERR* low. 

23. RULE 4.31: 

Once an INTERRUPT HANDLER has driven DSA* low, it MUST maintain a 
high on the WRITE* line until this minimum time after both data strobes are high. 
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Table 4-1 7. INTERRUPT HANDLER, Timing RULES And OBSERVATIONS (cont'd) 

24A. RULE 4.32: 

IF the INTERRUPT HANDLER drives or releases AS* to high after its 

REQUESTER releases BBSY*, 
THEN it MUST release lACK*, A01-A03, LWORD*, WRITE*, DSO*, and DS1* 

before allowing AS* to rise above the low level. 

24B. RULE 4.33: 

IF the INTERRUPT HANDLER drives or releases AS* to high before its 

REQUESTER releases BBSY*, 
THEN it MUST release lACK*, A01-A03, LWORD*. WRITE*, DSO*, and DS1* 

before changing its DEVICE WANTS BUS signal from true to false. 

25. RULE 4.34: 

IF the INTERRUPT HANDLER drives or releases AS* to high after its 

REQUESTER releases BBSY*, 
THEN it MUST release AS* within this time after allowing it to rise above the 

low level. 

26. OBSERVATION 4.16: 

Timing parameter 26 guarantees that the data bus will not be driven until the 
INTERRUPT HANDLER drives DSA* low. 

27. OBSERVATION 4.17: 

The INTERRUPT HANDLER is guaranteed that the data bus will be valid within 
this time after DTACK* goes low. This time does not apply to cycles where the 
INTERRUPTER drives BERR* low instead of DTACK*. 

28. OBSERVATION 4.18: 

The INTERRUPT HANDLER is guaranteed that neither DTACK* nor BERR* will 
go low until this minimum time after it drives DSA* low. The BUS TIMER 
guarantees the INTERRUPT HANDLER that if DTACK* has not gone low after its 
time-out period has elapsed, and within twice its time-out period, then the BUS 
TIMER will drive BERR* low. 

29. OBSERVATION 4.19: 

The INTERRUPT HANDLER is guaranteed that the data bus remains valid until 
it drives DSA* high. 

30. OBSERVATION 4.20: 

This guarantees that neither DTACK* nor BERR* goes high until the 
INTERRUPT HANDLER drives both DSO* and DS1* high. 

31. OBSERVATION 4.21: 

The INTERRUPT HANDLER is guaranteed that the data bus has been released 
by the time DTACK* and BERR* are high. 
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Table 4-18. INTERRUPTER, Timing RULES And OBSERVATIONS 

Note: The numbers correspond to the timing parameters specified in Table 4-16. 

4. OBSERVATION 4.22: 

"^J^?^4.'i'''"^'^^ are guaranteed that lACK*, LWORD*, and A01-A03 have been 
valid for this minimum time when they detect a falling edge on AS*. 

5. OBSERVATION 4.23: 

All INTERRUPTERS are guaranteed this minimum high time on AS* between 
DTB cycles. 

6. OBSERVATION 4.24: 

The responding INTERRUPTER is guaranteed that none of D00-D31 will be 

n-l-\®o„*^ ^!^l^}!i^^! '^°^"'® ""*'' ^^® responding INTERRUPTER releases 
DTACK and BERR to high. 

7. OBSERVATION 4.25: 

The responding INTERRUPTER is guaranteed that the data bus will be released 
by all other modules by the time DSA* goes low. 

9. OBSERVATION 4.26: 

The responding INTERRUPTER is guaranteed that neither DSO* nor DS1* will 
go low until DTACK* and BERR* from the the previous cycle have gone high. 

11. OBSERVATION 4.27: 

INTERRUPTERS are guaranteed this minimum time during which both data 
strobes are simultaneously high between cycles. 

12. OBSERVATION 4.28: 

INTERRUPTERS are guaranteed that WRITE* has been high for this minimum 
time when they detect a falling edge on DSA*. 

13. OBSERVATION 4.29: 

IF both data strobes are going to be driven low, 

THEN the responding INTERRUPTER is guaranteed that DSB* will go low 
within this maximum time after DSA*. 

And therefore: 

IF the DSB* does not go low within this maximum time, 

THEN the responding INTERRUPTER assumes that it is to respond with a 
single byte STATUS/ID. 
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Table 4-18. INTERRUPTER, Timing RULES And OBSERVATIONS (cont'd) 

14. OBSERVATION 4.30: 

The responding INTERRUPTER is guaranteed that LWORD* and A01-A03 will 
remain valid until it drives DTACK* or BERR* low, provided it does so within the 
bus time-out period. 

16. OBSERVATION 4.31: 

The responding INTERRUPTER is guaranteed that lACK* will remain low until it 
drives DTACK* or BERR* low, provided it does so within the bus time-out 
period. 

18. OBSERVATION 4.32: 

The responding INTERRUPTER is guaranteed that AS* will remain low until it 
drives DTACK* or BERR* low, provided that it does so within the bus time-out 
period. 

19. OBSERVATION 4.33: 

INTERRUPTERS are guaranteed that the AS* will remain low for this minimum 
time. 

20. OBSERVATION 4.34: 

The responding INTERRUPTER is guaranteed that once DSA* goes low, it will 
remain low until the INTERRUPTER has driven DTACK* or BERR* low, provided 
that the INTERRUPTER does so within the bus time-out period. 

21. OBSERVATION 4.35: 

The responding INTERRUPTER is guaranteed that once DSB* goes low, it will 
remain low until the INTERRUPTER has driven DTACK* or BERR* low, provided 
that the INTERRUPTER does so within the bus time-out period. 

23. OBSERVATION 4.36: 

INTERRUPTERS are guaranteed that the WRITE* line remains high until both 
data strobes are high. 

26. RULE 4.35: 

The INTERRUPTER MUST NOT drive the data bus until DSA* goes low. 

27. RULE 4.36: 

The responding INTERRUPTER MUST NOT drive DTACK* low before it drives 
the data lines with a valid STATUS/ID. 

OBSERVATION 4.37: 

This time does not apply to cycles where the INTERRUPTER drives BERR* low 
instead of DTACK*. 
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Table 4-18. INTERRUPTER, Timing RULES And OBSERVATIONS (cont'd) 

28. RULE 4.37: 

The responding INTERRUPTER MUST wait this minimum time after DSA* qoes 
low before driving DTACK* or BERR* low. 

29. RULE 4.38: 

Once the responding INTERRUPTER has driven DTACK* low, it MUST NOT 
change D00-D31 until DSA* goes high. 

30. RULE 4.39: 

Once the responding INTERRUPTER has driven DTACK* or BERR* to low it 
MUST NOT release it until it detects both DSO* and DS1* high. 

31. RULE 4.40: 

The responding INTERRUPTER MUST release all of D00-D31 before releasinq 
DTACK* and BERR* to high. ^ 

32. OBSERVATION 4.38: 

The responding INTERRUPTER is guaranteed that lACK*. LWORD*, and A01- 
A03 have been valid for this minimum time when it detects a falling edge on 
DSA*. This time is derived from timing parameters 4, and 10. 

34. OBSERVATION 4.39: 

The INTERRUPTER is guaranteed that AS* has been low for this minimum time 
when it detects a falling edge on lACKIN*. 

35. RULE 4.41: 

A participating INTERRUPTER MUST drive its lACKOUT* high within this 
maximum time after the rising edge on AS*. 

36. RULE 4.42: 

The INTERRUPTER MUST NOT drive the data bus until its lACKIN* line goes 
low. 

37. RULE 4.43: 

IF a participating INTERRUPTER drives the data bus, 

THEN it MUST release it before driving its lACKOUT* line low. 

38A. RULE 4.44: 

A participating INTERRUPTER MUST NOT drive its lACKOUT* line low, until it 
detects its lACKIN* line low. 

388. RULE 4.45: 

The responding INTERRUPTER MUST NOT drive its DTACK* line low, until it 
detects its lACKIN* line low. 
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Table 4-18. INTERRUPTER, Timing RULES And OBSERVATIONS (cont'd) 

39. OBSERVATION 4.40: 

This time guarantees that each INTERRUPTER'S lACKIN* line will go high 
within this time after the rising edge on AS*. This time is derived from timing 
parameter 35, where the lACK DAISY-CHAIN DRIVER and participating 
INTERRUPTERS are required to drive their lACKOUT* line high within a 
maximum time. 

40. OBSERVATION 4.41: 

All INTERRUPTERS are guaranteed that their lACKIN* line will stay high for this 
minimum time between consecutive DTB cycles. 

41. OBSERVATION 4.42: 

This time guarantees that A01-A03 and LWORD* remain valid until this time 
after the participating INTERRUPTER drives its lACKOUT* low, provided it does 
so within the bus time-out period. 

43. OBSERVATION 4,43: 

This time guarantees that AS* remains low for this minimum time after the 
participating INTERRUPTER drives its lACKOUT* low, provided it does so within 
the bus time-out period. 
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Table 4-1 9. lACK DAISY-CHAIN DRIVER, Timing RULES And OBSERVATIONS 

Note: The numbers correspond to the timing parameters specified in Table 4-16. 

OBSERVATION 4.44: 

Since the backplane connects lACK* to the slot 1 lACKIN*, these two signals 
are equivalent. And therefore, all RULES and OBSERVATIONS that apply to 
one, are applicable to the other as well. 

5. OBSERVATION 4.45: 

The lAGK DAISY-CHAIN DRIVER is guaranteed this minimum high time on AS* 
between DTB cycles. 

19. OBSERVATION 4.46: 

The lACK DAISY-CHAIN DRIVER is guaranteed that the AS* will remain low for 
this minimum time. This time is derived from timing parameters 6, 16, and 27 of 
the INTERRUPTER. 

32. OBSERVATION 4.47: 

The lACK DAISY-CHAIN DRIVER is guaranteed that lACK* (and the slot 1 
lACKIN*) has been valid for this minimum time when it detects a falling edge on 
DSA*. 

34. RULE 4.46: 

IF the lACKIN* line is low when the lACK DAISY-CHAIN DRIVER detects 

a falling edge on DSA*, 
THEN it MUST drive its lACKOUT* line low, but it MUST NOT do so until this 

time after the falling edge on DSA*. 

OBSERVATION 4.48: 

The lACK DAISY-CHAIN DRIVER does not drive its lACKOUT* line low every 
time DSA* goes low. It only does so when the lACK* line is low as well, 
indicating that an interrupt acknowledge cycle is in progress. 

35. RULE 4.47: 

IF the lACK DAISY-CHAIN DRIVER drives its lACKOUT* line low, 

THEN it MUST drive its lACKOUT* high within this time after the rising edge 
of AS*. 

40. RULE 4.48: 

The lACK DAISY-CHAIN DRIVER MUST NOT drive lACKOUT* low until it has 
been high for this minimum time. 

42. OBSERVATION 4.49: 

IF the lACK DAISY-CHAIN DRIVER drives its lACKOUT* line low within 

the bus time-out period, 
THEN this time guarantees that lACK* (and the slot 1 lACKIN*) remains valid 

for this time. 
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CHAPTER 5 
UTILITY BUS 

5.1 INTRODUCTION 

This Chapter identifies and defines the signal lines and modules which provide utility 
functions for the VMEbus. The Utility Bus supplies periodic timing, initialization and 
diagnostic capability for the VMEbus (See Figure 5-1). 

5.2 UTILITY BUS SIGNAL LINES 

The Utility Bus signal lines are listed below: 

System Clock (SYSCLK) 

Serial Clock (SERCLK) 

Serial Data (SERDAT*) 

AC Fail (ACFAIL*) 

System Reset (SYSRESET*) 

System Failure (SYSFAIL*) 

5.3 UTILITY BUS MODULES 

5.3.1 The SYSTEM CLOCK DRIVER 

The system clock is an independent, non-gated, fixed frequency, 16 MHz, 50 percent 
(nominal) duty cycle signal. The SYSCLK driver is located on the system controller 
are located in board slot one (see Chapter 1). It provides a known time base that is 
useful for counting off time delays. Figure 5-2 shows the SYSTEM CLOCK DRIVER 
timing diagram. 

OBSERVATION 5.1: 

SYSCLK has no fixed phase relationships with other VMEbus timing. 

5.3.2 The SERIAL CLOCK DRIVER 

The SERIAL CLOCK DRIVER provides a fixed frequency, special waveform signal 
used by VMSbus modules that reside on VMEbus boards. Its waveform is specified in 
the VMSbus specification. For the convenience of designers, the timing parameters in 
effect at the time that this document has been published are provided in Appendix C. 
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Figure 5-1. Utility Bus Block Diagram 
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Figure 5-2. SYSTEM CLOCK DRIVER Timing Diagram 



5.3.3 The POWER MONITOR 

Figure 5-3 is the block diagram for the POWER MONITOR module. This module 
detects power failures and signals the VMEbus system in time to effect orderly shut- 
down. When power is then reapplied to the system the POWER MONITOR ensures that 
all other VMEbus modules are initialized. 

The POWER MONITOR might also monitor a manually operated push button and 
initialize the VMEbus system whenever that button is depressed by the operator. 

The ACFAIL* and SYSRESET* transitions, and the point at which the system DC 
voltages violate specification, have certain timing relationships. These relationships 
are shown in Figures 5-4 and 5-5. 

PERMISSION 5.1: 

VMEbus systems MAY be built with or without a POWER MONITOR module. 

RULE 5.1: 

POWER MONITORS MUST comply with the timing given in Figures 5-4 and 5-5. 

PERMISSION 5.2: 

The SYSRESET* line MAY be driven low by any VMEbus board to initialize the 
system from a manual push-button. Where a board drives SYSRESET*, but does not 
drive ACFAIL*, the timing in Figure 5-4 and Figure 5-5 does not apply. 

RULE 5.2: 

Whenever any board drives SYSRESET* low, it MUST hold SYSRESET* low for a 
minimum period of 200 milliseconds. 
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Figure 5-3. Block Diagram Of POWER MONITOR Module 



5.4 SYSTEM INITIALIZATION AND blAGNOSTICS 

The VMEbus provides protocols which allow the system to be shut down and powered 
up in an orderly manner. Two signal lines are used in the power-down and power-up 
sequence: AGFAIL* and SYSRESET*. Another signal line is used in the power-up 
sequence: SYSFAIL*. 

The following specifies the behavior of VMEbus functional modules during the power- 
down sequence: 

RECOMMENDATION 5-1: 

Design MASTERS so that they do not request the bus for any purpose except power- 
fail activity, after AGFAIL* has been low for 200 microseconds. 
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RECOMMENDATION 5.2: 

THEN they are to limit tlieir subsequent non-power-fail activity to 200 microseconds. 
OBSERVATION 5.2: 

Bus accesses required to save and restore system data to VMEbus memory deoend 

S hS^ aPP"cation, and are not specified he?e. (The operatingl^emhasTo assure 

EpVSf ofT"^ ^r'"3 the shut-down process is restored prior to system operationO n 

m«^Jf!r ^®t®* (SYSRESET*) is an open-collector line driven by a POWER MONiTOR 
module, or by any board in response to a push-button switch closure. 

OBSERVATION 5.3: 

?Soi?'h''iS?'J^ "^^'^f'^ ""^^'^ push-button reset switches are used, to ensure that 

flvliJElET* fow°tSe" ""^"'^ ''°^''^ *° ^'°'^*^ *^^2°° milliseconds minkTium 
RULE 5.3: 
The SYSTEM CLOCK driver MUST continue to provide the soecified SYSCLK 
waveform regardless of the state of the SYSRESET* line. specmed bYSCLK 

PERMISSION 5.4: 

l!llm^r5I^?^?^r.-^°®? '°*' ^"y ^^^""^ that requires more than 200 milliseconds to 

irs&tvitteX "d*is °" "= '''"''''■ ""'' '°- '° ™'"'^^° 

RULE 5.4: 

"" iow^^° "^"^^"^ ^"^"^^^ '^ *'*'^'" '*^ specified range when SYSRESET* goes 

THEN functional niodules MUST satisfy the timing RULES givenin Table 5-1 within 
the specified time after SYSRESET* goes low. 

RULE i5: 

iTucM f^^ii'^^F*'!.'°*^'^®"t^® +5 Vdc enters its specified range, 

^ hon ISmot"'"?"'-®^, "^"^"^ ^^*'^*y t''® *'"^'"g RULES given in Table 5-1 and 
then MUST refrain from dnving specified lines until SYSRESET* goes high. 

RULE 5.6: 

ct^fl^fit^-"^.^-^® ^^^^? '" ^^'''® S-""' functional modules MUST NOT change the 
lSs^t°JiSSf?er;^gf '■ '''^^'^'' 3°- ^^'- -'- the .5 Vdc power ioVrSi 
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RULE 5.7: ^ owor..-orrn-* 

IF +5 Vdc power source is within the specified range when SYSRESET goes 

low and a MASTER or INTERRUPT HANDLER is driving AS*, DSO*, or DS1* 

low, . ^ ,. ■ I 

THEN it MUST maintain these strobes low long^enough to satisfy the minimum low 

times given in Chapters 2 and 4. 



Table 5-1. Module Drive During Power-Up And Power-Down Sequences 



MODULE 


MUST REFRAIN 
FROM DRIVING 


AFTER 
SYSRESET* 
HAS BEEN 
LOW FOR 


MASTERS and 
INTERRUPT HANDLERS 


AS*, DSO*. or DSr from 
high to low 


5 usee 


MASTERS and 
INTERRUPT HANDLERS 


lACK*, LWORD*, AS*, DSO*, 
DS1*,AM0-AM5, A01-A31 , WRITE*, 
orD00-D31 


20 usee 


SLAVES and 
INTERRUPTERS 


D00-D31 , DTACK*, or BERR 


30 usee 


INTERRUPTERS 


IRQ1*-IRQ7* 


30 usee 


BUS TIMER 


BERR* 


30 usee 


ARBITER 


BG0IN*-BG31N* from 
high to low 


5 usee 


ARBITER 


BG0IN*-BG3IN* low 


30 usee 


REQUESTERS 


BBSY* 


30 usee 
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SYSFAIL* is an open collector line that is held low when the system is powered-uo 
and remains low until system self-tests are complete (see Figure 5-6) The following 

SUGGESTION 5-1: 

On intelligent MASTER boards, include a locally accessible control reaister bit that k 
in^ialized to drive SYSFAIL* low when power is first applied to ZboSd This plrmits 
sJf-?esTp?ss°es '"*""9"""" '° ^° ^ '°^^' self-test and release SyIfail' on& ifll 



SUGGESTION 5-2: 

Design non-intelligent boards with a globaly accessible control reaister bit that i<; 
initialized fo drive SYSFAIL* low. This allows a MASTER oSe VmSus to run a test 

t°hVb^^rs-S;i^ATSe?^^ '''' ^''^ ^° ''' ^'°^^' ^°"^-' ^^^^ ^^ 
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SUGGESTION 5-3: 

Tfr nn^tif/ST^Hr* f°"l''°' '^^}^^^' ^^ '^ '"^'"d®d °" VMEbus boards. provide a status 
^ c?c?rn^ f .?°3''d s *ront panel to Indicate the status of the control register bit ThehTf 
^^!::^IS^^:S' SYSFAIL* Signal line, a visual inVctio^n ^S^l^ 



RULE 

IF 

THEN 



5.8: 

£"^^^.^1^1^°"*''°' ""©Sister bits are included on VMEbus boards 

they MUST drive SYSFAIL* low within 50 milliseconds after SYSRESET* 

goes low, as shown in Figure 5-6. oncot i 

PERMISSION 5.4: 

A VMEbus board MAY also drive SYSFAIL* low at any time during normal operation 
to indicate that it has detected some kind of failure. operation 



SYSRESET* 




0.8 



0.8 



/ 



200 ms 
' MIN 



50 ms 
' MAX "■ 



SYSFAIL* 



TEST IN PROGRESS . . . TEST PASSES 



K 



2.0 




Figure 5-6. SYSRESET* And SYSFAIL* Timing Diagram 
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5.5 POWER PINS 

Figure 5-7 gives the current rating for the VMEbus power pins at various temperatures. 

OBSERVATION 5.4: 

Some connector pins have a slightly higher contact resistance than others when 
plugged into the backplane. This produces unbalanced current flow in pins which are 
paralleled. Suppose that two pins are paralleled and are carrying a total of two 
amperes of current. If the contact resistance on one is 1 milliohm and the other is 2 
milliohms, then one pin will be carrying only 0.67 amperes while the other carries 1 .33 
amperes! 

RULE 5.9: 

VMEbus connector pins MUST be capable of carrying the currents shown by the solid 
line in Figure 5-7. 

OBSERVATION 5.5: 

If one or more power pins fail completely, all of the load current flows through the 
remaining pins. For example, if half of the pins fail, the remaining pins carry twice the 
normal current. Depending upon the load current, this might cause damage to these 
remaining good pins. 

SUGGESTION 5-4: 

When designing a VMEbus board with a high current load, divide the board's area into 
zones which are each powered by a separate power grid. Don't connect these grids to 
each other on the VMEbus board. Instead, connect each to its own VMEbus power pin. 

OBSERVATION 5.6: 

IF a double height VMEbus board which draws more power than its P1 

connector can provide is plugged into a subrack which contains only a J1 
backplane, 

THEN its P1 power pins will overheat, and might be damaged. 

5.6 RESERVED LINE 

RULE 5.10: 

The VMEbus specification labels one signal line as RESERVED. The RESERVED line 
is terminated and bused. This line is set aside for future use and MUST NOT be 
used in any VMEbus board designs. 
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Notes: 



*'C AMBIENT 



1 . The dotted line shows the upper limit for current that can be safely drawn per 
board. 



+5 Vdc power pin where two or more pins are connected to a common on- 



2. The solid line sliows the upper limit for current that can be safely drawn per 
+5 Vdc power pin where each pin is connected to a separate power grid. 

Figure 5-7. Cun-ent Rating For Power Pins 
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CHAPTER 6 
ELECTRICAL SPECIFICATIONS 



6.1 INTRODUCTION 

The transmission of data between VMEbus boards such as processors, memories and 
I/O devices takes place over one or two backplanes, depending on the design. The 
rules in this chapter ensure proper timing, minimal noise and minimal cross talk 
problems on the backplane signal lines. The design of VMEbus backplanes is 
governed by the following RULES: 

RULE 6.1: 

VMEbus backplanes MUST NOT have any signal conductors longer than 500 mm 
(19.68 inches). 

RULE 6.2: 

VMEbus backplanes MUST NOT have more than 21 slots. 

RULE 6.3: 

For those lines requiring termination (see Section 6.7) the backplane MUST provide 
some means for terminating them at both ends of the signal line. 

RULE 6.4: 

The backplane MUST provide power conductors for distribution of +5V, +5V STDBY, 
+12V, and -12V to all of the power pins specified in Section 7.6. 

RULE 6.5: 

The backplane MUST provide ground connections to all of the ground pins specified 
in Section 7.6. 

PERMISSION 6.1: 

VMEbus signal lines are normally driven by bipolar drivers, but any technology which 
complies with this specification MAY be used. 

6.2 POWER DISTRIBUTION 

Power in a VMEbus system is distributed on the backplane(s) as regulated direct 
current (DG) voltages. The available voltages are: 

+5 vdc This is the main power source for most VMEbus systems. Most of 

the system circuitry, including TTL logic, MOS microprocessors, 
and memories, requires this voltage. 
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ELECTRICAL SPECIFICATIONS 



±12Vdc 



+5 Vdc STDBY 



These are often used for powering RS232C drivers. They are also 
sometimes used for powering MOS and analog devices. In some 
cases -5 Vdc bias voltage or -5.2 Vdc EC L voltages are also 
derived from the -12 Vdc source using on-board regulators. These 
supplies normally don't supply as much power to the VMEbus 
system as the +5 Vdc source does. 

This is used to sustain memory, time-of-day clocks, etc, when the 
+5 Vdc power is lost. 
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6.2.1 DC Voltage Specifications 

Table 6-1 summarizes the DC voltage specifications. The listed specifications are the 
maximum allowed variance as measured at the connector pins of any card pluaaed 
mto the backplane. <- j h ««=« 

RECOMIUIENDATION 6.1: 

Design and connect backplanes so that the power supply sense point is located 
somewhere near the center of the backplane, and as close as possible to the point 
where power IS introduced into the backplane. « pu'iu 

OBSERVATION 6.1: 

fh^^!!!P *'^® power supply sense point near the power input point prevents boards near 
the power input point from receiving too high a voltage. 



Table 6-1 . Bus Voltage Specification 



ALLOWED RIPPLE/NOISE 

MNEMONIC DESCRIPTION (see^OBsSlVATION 6.2) ^PMl^to^^^^^^ 



+5V 



+5 Vdc 



+0.25V/ -0.125V 



50 mV 



+12V 



+12 Vdc power 



+0.60V/ -0.36V 



50 mV 



-12V 



-12 Vdc power 



-0.60V /+0.36V 



50 mV 



+5V STDBY +5 Vdc standby 



GND 



Ground 



+0.25V/-0.125V 



REFERENCE 



50 mV 
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OBSERVATION 6-2: 

The non-symmetric variation given in Table 6-1 ensures that the DC power remains 
within the tolerance required by most ICs despite the typical voltage drops that occur in 
the power distribution network. 

OBSERVATION 6.3: ^ . 

The power consumed by some systems fluctuates over a wide range dunng normal 
system operation. For example, dynamic memory refreshing might cause significant 
fluctuations if large amounts of memory are refreshed at one time. In this case the 
response time of the voltage distribution system becomes important. 

RECOMMENDATION 6.2: 

Use bypass capacitors on VMEbus boards to minimize the effects of power transient. 

6.2.2 Pin And Socket Connector Electrical Ratings 

RULE 6.6: 

The 96 pin connector used by the VMEbus MUST provide the following: 

Voltage rating: > 100 volts DC, isolation pin to pin 

Contact resistance: < 50 milliohms, at rated current 

Insulation resistance: > 100 Megohms, pin to pin 

6.3 ELECTRICAL SIGNAL CHARACTERISTICS 

RULE 6.7: .. . * ^ ♦ ♦ 

VMEbus boards MUST NOT drive any backplane signal line to a higher steady-state 
voltage than the highest voltage on any of its +5V power pins, or to a lower steady- 
state voltage than the lowest voltage on any of its GND pins. 

RULE 6.8: .u x .. 

VMEbus boards MUST use drivers and receivers that meet the following 

characteristics: 

Steady-state driver low output level < 0.6 V 

Steady-state receiver low input level ^ 0.8 V 

Steady-state driver high output level > 2.4 V 

Steady-state receiver high input level < 2.0 V 

Figure 6-1 gives a simple graphic representation of these levels. 

VMEbus boards drive the backplane lines with three-state, open collector, and totem- 
pole drivers. Section 6.4 specifies the drive and loading requirements for the vanous 
signal lines. Section 6.7 provides a summary, showing which types of dnvers are 
used to drive each signal line. 
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Figure 6-1. VMEbus Signal Levels 



2.94V 
2.4 V 


— High Level — 


2.0 V 


IIIIIIIIIIIIIIHIIIIHIIIIIIIIIII 


0.8 V 


Transition Region 


0.6 V 


lllllllllllllllllllllllllllllllll 




Low Level 



V (Terminator) 
Voh min 



<— STEADY STATE 

Vih min NOISE MARGIN 

Vil max 

<— STEADY STATE 

Vol max NOISE MARGIN 



RULE 6.9: 



Wheri makmg voltage threshold measurements on a VMEbus board to verifv 
comp ance with timing specifications, the ground reference MUST be taken from the 

S h2 mJS P'"H"^^'f * J^^^'S"^' P'" ^^'"9 measured, and the signal Sage 
MUST be measured on the board's connector pin. vuitage 

96.4 BUS DRIVING AND RECEIVING REQUIREMENTS 
Tab%^?S°Tis1f afoMhl^^JL^^i"^ '^""f^l «P«c"'cations for all VMEbus signal lines, 
discusses it. ^ ^""^ ^''°''^ '"^''''^ °* *^® *°"°*'"9 subsections 

6.4,1 Bus Driver Definitions 

Totem-pole, three-state, and open-collector drivers are defined as follows: 

Totem-pole - an active driver in both states which sinks current in the low state and 
sources current in the high state. Totem-pole drivers are used on sisals hatJna oniv 
a single dnver per line (e.g.. daisy-chain lines). ^ ^ °"'^ 

If off ®/w -^^^ ": ^'"^'L^'' 1?. ^ totem-pole driver except that it can go to a high impedance 
state (drivers turned off) in addition to low and high logic states. Threi-stSe drfverl 

rn"?d^HS:i'"'Vf ^V^^^^'o^r" ^y ^^^^^^' d^^'^^' ^t differen pSnts on the bus 
(e.g.. address or data lines). Only one of these drivers can be active at any one tim^ 

SSTi"rfh°cfo?I°''T ^'"''^ ^^'■''®"* !" *^® '°^ s*^*^ b"* sources no significant current in 
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Table 6-2. Bus Driving And Receiving Requirements 



SIGNAL NAME 


SUB-SECTION 




6.4.2.x 


A01-A31 


2 


ACFAIL* 


5 


AM0-AiVI5 


2 


AS* 


1 


BBSY* 


5 


BCLR* 


3 


BERR* 


5 


BG0OUT*-BG3OUT* 


4 


BR0*-BR3* 


5 


D00-D31 


2 


DSO* 


1 


DS1* 


1 


DTACK* 


5 


lACK* 


2.5 


lAGKOUr 


4 


IRQ1*-IRQ7* 


5 


LWORD* 


2 


SERCLK 


3 


SYSOLK 


3 


SYSFAIL* 


5 


SYSRESET* 


5 


WRITE* 


2 
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6.4.2 Driving And Loading RULES For All VMEbus Lines 

RULE 6.10: 

All VMEbus boards MUST provide clamping on each VMEbus signal line that they 
monitor to prevent negative excursions below -1 .5 V. 

OBSERVATION 6.4: 

Standard 74LSxxx and 74Fxxx devices have internal clamping diodes on their inputs 
that will satisfy the clamping requirement specified in RULE 6.10. 

RULE 6.11: . u .-. 

VMEbus receivers MUST guarantee detection of a high logic level above a threshold 
of 2.0 volts, as shown in Figure 6-1 . 

RULE 6.12: . . ,^ 

VMEbus receivers MUST guarantee detection of a low logic level below a threshold 
of 0.8 volts, as shown in Figure 6-1 . 
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PERMISSION 6.2: 

enabfe^d^*^*® ^"^^"^ "^^^ ^^ "^®^ ^^ ^ totem-pole driver if its output is permanently 

6.4.2.1 Driving And Loading RULES For High Current Three-State Lines 

(AS*, DSO*, DS1*) 

RULE 6.13: 

IF a VMEbus board drives AS*, DSO*, or DS1*, 

THEN its drivers for these lines MUST meet the following specifications: 

Low state sink current: jOL ^ 64 mA 

Low state voltage: VOL s 0.6V at lOL = 64 mA 

High state source current: lOH > 3 mA 

High state voltage: VOH s 2.4V at lOH = 3 mA 

Minimum source current 

with board pin grounded: lOS s 50 mA at OV 

Maximum source current 

with board pin grounded: JOS < 225 mA at OV 

RULE 6.14: 

!llH®n<?il''f' l^'l turned off VMEbus boards MUST limit their loading of AS*. DSO*, 
and DS1* to the following values: >i , ^^ , 

Current sourced by board at 0.6 V, 

including leal<age current: lOZL+IIL ^ 450 uA 

Current sunk by board at 2.4 V, 

including leakage current: lOZH+IIH < 100 uA 

Total capacitive load on signal, 

including signal trace: CT < 20 pF 

OBSERVATION 6.5: 

The source and sink currents listed in RULES 6.13 and 6.14 include both driver and 
receiver currents sourced and sunk on the board. 

SUGGESTION 6.1: 

Use 74S241 or 74F241/244 devices to drive the lines AS*, DSO*, and DS1* 

nlh^^'^^' '''^'-^241, or 74LS244 devices to receive the lines AS*, DSO*, and 
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6.4.2-2 Driving And Loading RULES For Standard Three-State Lines. 

(A01-A31, D00-D31, AM0-AM5, lACK*, LWORD*, WRITE*) 

RULE 6.15: 

IF a VMEbus board drives the lines A01-A31, D00-D31, AM0-AM5, lACK*, 

LWORD*, or WRITE*, 
THEN its drivers for these lines MUST meet the following specifications: 

Low state Sink current: lOL > 48 nnA 

Low state voltage: VO < 0.6V at lOL = 48 mA 

High state source current: lOH > 3 mA 

High state voltage: VOH > 2.4V at lOH = 3 mA 

Minimum source current 

with board pin grounded: 108 > 50 mA at OV 

Maximum source current 

with board pin grounded: 108 < 225 mA at OV 

RULE 6.16: H 

When drivers are turned off, VMEbus boards MUST limit their loading of the lines Kj 
A01-A31 , D00-D31 , AM0-AM5, JACK*, LWORD*, and WRITE* to the following values: B| 

Current sourced by board at 0.6 V, 

including leakage current: lOZL+IIL < 700 uA 

Current sunk by board at 2.4 V, 

including leakage current: lOZH+IIH < 150 u A 

Total capacitive load on signal, 

including signal trace: CT < 20 pF 

OBSERVATION 6.6: 

The source and sink currents specified in RULES 6.15 and 6.16 include both dnver 
and receiver currents sourced and sunk on the board. 

SUGGESTION 6.2: ^ . 

Use 74ALS645-1, 74F244, 74A8573, or 74A8580 devices to drive the lines A01-A31, 
D00-D31 , AM0-AM5, lACK*, LWORD*, and WRITE*. 

Use 74L8240, 74LS241, or 74LS244 devices to receive the lines A01-A31, D00-D31, 
AM0-AM5, JACK*. LWORD*, and WRITE*. 

Use 74ALS645-1, 74AL8245A-1, 74ALS646-1, or 74ALS648-1 devices to transceive 
the lines A01 -A31 , D00-D31 , AM0-AM5, lACK*, LWORD*, and WRITE*. 
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6.4.2.3 Driving And Loading RULES For High Current Totem-Pole Lines 

(SERCLK, SYSCLK, BCLR*) 

RULE 6.17: 

SERCLK %Yiri\^^rVn,^i*%''°J^°'^ l*"^" °"® ''^^^^ ^"^'"9 each of the lines 
s ecifi t' ' ^"-^ • '^^ <i'^*^ers for these lines MUST meet the following 

Low state sink current: lOL > 64 mA 

Low state voltage: VOL < 0.6V at lOL = 64 mA 

High state source current: lOH > 3 mA 

High state voltage: VOH > 2.4V at lOH = 3 mA 

Minimum source current 

with board pin grounded: 108 > SOmAatOV 



Maximum source current 



c 



I 



With board pin grounded: lOS < 255 mA at OV 

RULE 6.18: 

5r/p^^^?h "J^.f ^^ "^"ST limit their loading of the lines SERCLK, SYSCLK, and 
dOLR to the following values: 

Current sourced by board at 0.6 V, 

including leakage current: ' lOZL+IIL < 600 uA 

Current sunk by board at 2.4 V, 

including leakage current: lOZH+IIH < 50 uA 

c ■ ■ ■ ' 
Total capacitive load on signal, 

including signal trace, for system 

controllers (which have drivers): CT < 20 pF 

Total capacitive load on signal, 
including signal trace, for other 
boards (which have no drivers) CT ^ < 12 pF 

OBSERVATION 6.7: 

The source and sink currents specified in RULES 6.17 and 6.18 include JDoth driver 
and receiver currents sourced and sunk on the board. 

SUGGESTION 6.3: 

Use 74S241 or 74F241/244 devices to drive the lines SERCLK, SYSCLK, and BCLR* 

Use 74LS240, 74LS241 or 74LS244 devices to receive the lines SERCLK SYSCLK 

and BCLR*. ' ' 
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6-4.2.4 Driving And Loading RULES For Standard Totem-Pole Lines 

(BG0OUT*-BG3OUT*/BG0IN*-BG3INMACKOUT7IACKIN*) 

RULE 6.19: 

IF a VMEbus board drives the lines BG0OUT*-BG3OUT*/BG0IN*-BG3IN*, or 

IACK0UT7IACKIN*, 
THEN its drivers for these lines MUST meet the following specifications: 

Low state sink current: lOL > 8 mA 

Low state voltage: VOL < 0.6V at lOL = 8 mA 

High state source current: lOH > 400 uA 

High state voltage: VOH > 2.7V at lOH = 400 uA 

RULE 6.20: 

All VMEbus boards MUST limit their loading of each of the lines BG0OUT*-BG3OUT7 
BG0IN*-BG3IN*, and IAGK0UT7IACKIN* to the following values: 

Current sourced by board at 0.6 V, 

including leakage current: lOZL+IIL < 600 uA 

Current sunk by board at 2.4 V, 

including leakage current: lOZH+IIH < 50 uA 

Total capacitive load on signal, 

including signal trace: CT < 20 pF 

OBSERVATION 6.8: 

The source and sink currents specified in RULES 6.19 and 6.20 include both driver 
and receiver currents sourced and sunk on the board. 

SUGGESTION 6.4: 

Use any standard device that meets the specifications above to dnve the lines 
BG0OUT*-BG3OUT7BG0IN*-BG3IN*, and IACK0UT7IACKIN*. 

Use 74LS240, 74LS241, or 74LS244 devices to receive the lines BG30UT*- 
BG3OUTVBG0IN*-BG3IN*, and IACK0UT7IACKIN*. 



I 



203 



ELECTRICAL SPECIFICATIONS 

6.4.2.5 Driving And Loading RULES For Open-Collector Lines 

(BR0*-BR3*, BBSYMRQr-|RQ7*, DTACK*, BERR*. 
SYSFAIL*, SYSRESET*, ACFAIL*, and lACK*) 

RULE 6.21: 

IF a VMEbus board drives the lines BR0*-BR3*, BBSY* iRQl*-IRQ7* DTAOK* 

^^.» ^^^^*- SYSFAIL*. SYSRESEr, ACFAIL*. or lACK*. ' ' 

THEN Its dnvers for these lines MUST meet the following specifications: 



Low state sink current: 
Low state voltage: 



lOL > 
VOL < 



48 mA 

0.6V at lOL = 48 mA 



RULE 6.22: 

All VMEbus boards MUST limit their loading of the lines BR0*-BR3* BBSY* IR01*- 
Ses'-'"''''^^*' ^^''''*' ^^^'''"'-*' SYS'^ESEr, ACFAIL*. and lACK* to the following 



Current sourced by board at 0.6 V, 

including leakage current: lOZL+IIL 



i 



400 uA (DTACK* and 

BERR*) 
600 uA (all others) 



Current sunk by board at 2.4 V, 
including leakage current: 

Total capacitive load on signal, 

including signal trace: CT 



lOZH+IIH s 50 uA 



20 pF 



OBSERVATION 6.9: 

The sink current specified in RULES 6.21 and 6.22 includes both driver and receiver 
currents sourced and sunk on the board. 

SUGGESTION 6.5: 

Use 74838 devices to drive the lines BR0*-BR3*, BBSY* IRQ1*-!RQ7* DTAOK* 
BERR*, SYSFAIL*. ACFAIL*. and lACK*. . i"ui inu/ , UIAOK , 

Use 74LS240, 74LS241 , or 74LS244 devices to receive the lines BR0*-BR3* BBSY* 
IRQ1*-IRQ7*, DTACK*, BERR*, SYSFAIL*, SYSRESET*, ACFAIL*, and JACK* ' 

SUGGESTION 6.6: 

Since most TTL drivers do not work reliably when the +5 Vdc power source is out of its 
specified range, drive SYSRESET* on a POWER MONITOR module with a driver built 
from a discrete high-gain small signal transistor. 
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6.5 BACKPLANE SIGNAL LINE INTERCONNECTIONS 

The VMEbus is a high performance interface system. Its design takes into account 
transmission line effects on the backplane. The address and data set-up times 
specified in Chapters 2 and 4 take into account the fact that most drivers available 
today do not reliably drive backplane signal lines from the low to the high level until 
there is a reflection from the end of the bus. Although these reflections serve a useful 
purpose, they cannot be excessive or ringing will result. The following paragraphs 
specify the backplane characteristics that achieve the desired result. 

6.5.1 Termination Networks 

RULE 6.23: 

Termination networks MUST be used on each end of all VMEbus signal lines except 
the daisy-chain lines. 

OBSERVATION 6.10: 

The terminations in the VMEbus serve four purposes: 

They reduce reflections from the ends of the backplanes. 

They provide a high state pull-up for open-collector drivers. 

They restore the signal lines to the high level when three-state devices are 

disabled. / 

They provide a standing current for the driver sink transistor to switch off, 

causing the signal line to rise more swiftly on positive transitions. 

The Thevenin equivalent of the termination is shown in Figure 6-2. The voltage divider 
also shown provides this termination value. 

OBSERVATION 6.11: 

IF a maximum tolerance of ± 5% is maintained on the resistor values and source 

voltage used in the resistor network shown in Figure 6-2, 
THEN the circuit shown will meet the tolerances shown for the Thevenin equivalent. 

OBSERVATION 6.12: 

The resistor network shown in Figure 6-2 presents its Thevenin equivalent impedance 
only when its +5V source is adequately decoupled to ground by a bypass capacitor. 

RECOMMENDATION 6,3: 

Provide a bypass capacitor with a value in the range of 0.01 to 0.1 uF as close as 
possible to the Vcc pin of each resistor termination package. 

PERMISSION 6.3: 

Any resistor network and voltage source MAY be used to provide the termination, as 
long as they provide the Thevenin equivalent shown in Figure 6-2. 
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+5V + 5% 



+5V + 5% 




SIGNAL LINE 




I 



RESISTOR NETWORKS THAT PROVIDE 
THE REQUIRED TERMINATIONS 



R = 194 1 5% V = 2.94 + 10% 



-AAAr- 



-^ 



± 



THEVENIN EQUIVALENT 
FOR EACH TERMINATOR 



J 



Figure 6-2. Standard Bus Termination 
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6.5.2 Characteristic Impedance 



Each signal line in the backplane has an associated characteristic impedance Zo. 
This characteristic impedance is important because discontinuities in Zo (due to 
capacitive effect and loads on the bus) and mismatches between Zo and the 
terminations can cause distortions of signal waveforms. 

Figure 6-3 shows a microstrip signa^ine cross Section which is the normal 
configuration for a multilayer backplane signal line. The Zo is a function of the width 
and thickness of the line, the thickness of the dielectric, and its relative dielectric 
constant. Figure 6-4 shows characteristic impedance versus microstrip line width for 
common thickness of fiberglass-epoxy board. More information on Microstrip lines can 
be found in the MECL System Design Handbook, Motorola, 1983. 

The terminations on the VMEbus signal lines reduce distortion of their signal 
waveforms. Although a perfect impedance match (which totally eliminates distortions 
due to reflections) is not maintained between the termination networks and the signal 
lines, it is important not to allow too great a mismatch, as might be the case if a signal 
line's Zo value is too low. 

RECOMMENDATION 6.4: 

When designing a VMEbus backplane, choose a signal line width and board thickness 
that gives a Zo (as calculated from Figure 6-4) as close as possible to 100 ohms. 

The actual characteristic impedance of a backplane signal line is called the effective 
characteristic impedance (Zo'), and will be lower than Zo, due to the capacitance of 
plated-through holes and connector pins. This additional capacitance makes Zo' go 
below 100|ohms. Although plated-through holes are necessary to accommodate 
connectors, other holes should be kept to a minimum. 



MICROSTRIP LINE 



B 




VOLTAGE PLANE 



Figure 6-3. Backplane Microstrip Signal Line Cross Section 
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The backplane signal line impedance (without any boards plugged into the 
backplane) can be calculated with the following equation: 



where: 



] 



Zo" = 



Zo 



/ 



1 + Gd/Co 



Zo = 



The impedance of the microstrip line, ignoring the loading 
effects of plug-in pc boards, connectors, and plated-through 
holes. (See Figure 6-4) 

The distributed capacitance, per unit of distance, of the 
plated-through holes, and backplane connectors. 

The intrinsic line capacitance, per unit of distance, of the 
microstrip line, ignoring the loading effects of plug-in pc 
boards, connectors, and plated-through holes. (See Figure 
6-5) 

The backplane signal line impedance, including the loading 
effects of connectors, and plated-through holes but 
excluding the loading effects of plug-in pc boards. 

OBSERVATION 6.13: 

Typical Zo' values for a VMEbus backplane with no boards inserted, range from 50 to 
60 ohms. If this impedance is 50 ohms, or higher it will provide satisfactory operation. 



Cd = 



Co = 



Zo' = 



6.5.3 Additional Information 

RULE 6.24: 

Circuit traces from the 96 pin connectors to the on-board circuitry MUST NOT have a 
length of greater than 50.8 mm (2 inches). 

OBSERVATION 6.14: 

IF the trace from the 96 pin connector to on-board circuitry branches, 

THEN the length of each branch is added to get the total length specified in RULE 
6.24. 

RULE 6.25: 

There MUST NOT be more than one driver driving the SYSCLK and SERCLK lines. 

RULE 6.26: 

IF the SYSTEM CLOCK DRIVER and the SERIAL CLOCK DRIVER modules are 

provided, 
THEN they MUST be installed in slot 1 of the backplane. 
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OBSERVATION 6.15: 

Locating the SYSTEM CLOCK DRIVER and the SERIAL CLOCK DRIVER on the board 
in slot 1 minimizes the distortion of their waveforms from the reflections off the ends of 
the backplane. 

SUGGESTION 6.7: 

If actual capacitance loading values cannot be obtained from manufacturer 
specifications sheets, the following values can be used to estimate the total capacitive 
loading of a VMEbus board: 

The typical capacitance of a receiver 3-5 pf 

The typical capacitance of a driver 1 - 1 2 pf 

The typical capacitance of a transceiver 15-18pf 

The typical capacitance of a 50.8 mm (2 inches) PC trace 2-3pf 

OBSERVATION 6. 16: 

Circuit traces which run parallel to each other, such as in a backplane, sometimes 
induce signal transitions in each other. This phenomenon is commonly known as 
cross talk. When designing VMEbus backplanes, the spacings of lines and their 
position relative to ground and power planes have a large effect on the amount of 
cross talk observed. 

SUGGESTION 6.8: ^ 

Propagation delays through bus drivers depend on how heavily they are loaded and HI 
VMEbus signal lines typically represent heavy loads. This has to be taken into K 
account when calculating worst case timing. If the manufacturer's data sheet for the Bj 
driver gives a propagation delay for a 300 pf load, use that to do the worst case 
calculations. If the only propagation delay values are for a 30 pf load, add 1 ns to the 
propagation delay and 15 ns to the turn-on delay. 

6.6 USER DEFINED SIGNALS 

RECOMMENDATION 6.5: 

If a board has a 96 pin connector in its P2 location, do not allow any of the P2 pins to 
be driven to a voltage greater than ±15V. This reduces the likelihood of serious 
damage to the VMEbus system in the event that a signal trace from one of these pins is 
accidently shorted to some other signal line. 
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6.7 SIGNAL LINE DRIVERS AND TERMINATIONS 

This Section summarizes the types of drivers which have to be used for each of the 
signallines on the VMEbus. 

In order to simplify Table 6-3, an abbreviated notation is used to describe the various 
types of drivers. The notations used are shown below: 



Totem-pole (high current) 
Totem-pole (standard) 
Three-state (high current) 
Three-state (standard) 
Open-collector 



TP HO 
TPSTD 
3 HO 
3STD 
00 



For detailed specifications, see Section 6.4. 



Table 6-3. Bus Driver Summary 



I 



SIGNAL 
MNEMONIC 


SIGNAL 
NAME 


DRIVER 
TYPE 


BUSED AND 
TERMINATED? 


A01-A31 
(31 lines) 


ADDRESS BUS 


3STD 


YES 


ACFAIL* 


AC POWER FAILURE 


OC 


YES 


AM0-AM5 
(6 lines) 


ADDRESS MODIFIER 


3STD 


YES 


AS* 


ADDRESS STROBE 


3HC 


YES 


BBSY* 


BUS BUSY 


OC 


YES 


BCLR* 


BUS CLEAR 


TPHC 


YES 


BERR* 


BUS ERROR 


OC 


YES 


BG0IN*-BG3IN* 

BGOOUr-BGSOUr 

(Daisy-chain) 


BUS GRANT DAISY-CHAIN 


TPSTD 


NO 


BR0*-BR3* 
(4 lines) 


BUS REQUEST 


OC 


YES 
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Table 6-3. Bus Driver Summary (cont'd) 



SIGNAL 
MNEMONIC 


SIGNAL 
NAME 


DRIVER 
TYPE 


BUSED AND 
TERMINATED? 


D00-D31 
(32 lines) 


DATA BUS 


3STD 


YES 


DS0*-DS1* 
(2 lines) 


DATA STROBES 


3HC 


YES 


DTACK* 


DATA TRANSFER 
ACKNOWLEDGE 


OC 


YES 


JACK* 


INTERRUPT ACKNOWLEDGE 


3STD 
orOC 


YES 


IACKIN*/IACKOUT* 
(Daisy-chain) 


INTERRUPT ACKNOWLEDGE 
DAISY-CHAIN 


TPSTD 


NO 


IRQ1*-IRQ7* 
(7 lines) 


INTERRUPT REQUEST 


OC 


YES 


LWORD* 


LONGWORD 


3STD 


YES 


RESERVED 


RESERVED 





YES 


SERCLK 


SERIAL CLOCK 


TPHC 


YES 


SERDAr 


SERIAL DATA 


OC 


YES 


SYSCLK 


SYSTEM CLOCK 


TPHC 


YES 


SYSFAIL* 


SYSTEM FAILURE 


OC 


YES 


SYSRESET* 


SYSTEM RESET 


OC 


YES 


WRITE* 


WRIIh 


3STD 


YES 



I 
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CHAPTER 7 
MECHANICAL SPECIFICATIONS 



7.1 INTRODUCTION 

Information is provided in this chapter to ensure that the VMEbus board assemblies, 
backplanes, subracks, and associated mechanical accessories are dimensionally 
compatible. 

The mechanical dimensions given in this chapter conform to lEC publications 297-1, 
297-3, 297-3A and 603-2. The electrical characteristics for VMEbus connectors, as 
specified in Chapters 5 and 6 supercede publication 603-2 where they differ. 

lEG publication 603-2 describes a family of connector types which are identified by 
labels of the form: 

603-2-IEC-xxxxxx-xxx 

All of the P1/J1 and P2/J2 connectors used on VMEbus boards and backplanes are 
members of this family. In this chapter, the label 603~2-IEC-xxxxxx-xxx is used when 
referring to all of these connector types as a group. The label 603-2-IEG-C096Mx-xxx 
is used when referring to the 96-pin male connector types within this family which are 
used on VMEbus boards. 603-2-IEC-C096Fx-xxx is used when referring to the 96-pin 
female connector types which are used on VMEbus backplanes. 

Figure 7-1 is a front view of a 19-inch width subrack which shows how single height 
and double height VMEbus boards can be mixed in a single subrack. Boards are 
inserted into the subrack from the front, in a vertical plane with the component face of 
the board on the right. 

PERMISSION 7.1: 

A VMEbus system MAY be composed of single height boards, double height boards, 
or a mixture of both. 

RULE 7.1: 

Single height VMEbus subracks MUST have a single "J1" backplane. 

RULE 7.2: 

Double height VMEbus subracks MUST have 

1 ) a "J1 " backplane mounted in the upper portion of the subrack, 

OR 

2) a "J1" and a "J2" backplane, with the J1 backplane mounted in the upper 
portion and the J2 backplane mounted in the lower portion. 

OR 

3) a double height backplane which provides both J1 and J2 connectors. 

RULE 7.3: 

VMEbus backplanes MUST NOT have more than 21 slots. 



215 



i 



MECHANICAL SPECIFICATIONS 

PERMISSION 7.2: 

When using backplanes of fewer than 21 slots, the VMEbus subrack MAY be less than 
the standard 482.6 mm (1 9 inches) rack size. 

RULE 7,4: 

Except for the rack width, which varies depending on the number of slots it supports 
all subrack dimensions MUST agree with those given in this chapter to ensure 
mechanical compatibility between the boards and the subrack. 

7,2 VMEbus BOARDS 

RECOMMENDATION 7,1: 

Make VMEbus boards 1 .6 ±0.2 mm (0.063 ±0.008 inch) thick. 

OBSERVATION 7,1: 

The thickness of VMEbus boards is important because the subrack's guide rails are 
designed to accommodate boards of this thickness. Thicker boards might not fit into 
the guides and thinner boards might not be guided properly into the backplane's J1 
and J2 connectors. 

OBSERVATION 7,2: 

The dimensioning of the 603-2-IEC-xxxxxx-xxx connectors provides a certain distance 
between the connector's mounting face and the center line of each of the connector's 
pins. This ensures that the P1 and P2 connector pin centers will align properly with 
the J1 and J2 connectors of the backplane. 

I PERMISSION 7.3: 
VMEbus boards MAY be designed with board thicknesses greater than 1.6 mm (0 063 
inch) if: ^ 

1 , the thickness of the top and bottom edges of the board, which fit Into the gulderails 
IS reduced to 1.6 mm (0.63 inch) for distance of 2.5 mm (0.098 inch) from the top and 
bottom edges of the board (See Figure 7-2 and Figure 7-3) and, 
2, the mounting surface provided by the board for the lEG 602-3 connector(s) is 4 07 
mm (0.160 inch) from the interboard separation plane. (See Figure 7-5) 

Two board sizes are defined as standard VMEbus boards: single height and double 
height (see Figure 7-2 and Figure 7-3). 

7,2,1 Single Height Boards 

OBSERVATION 7.3: 

A single height VMEbus board is 100mm (3.937 inch) high and 160 mm (6.299 inch) 
deep with an area of approximately 160.0 sq. cm (24.8 sq. inch). 
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RULE 7.5: 

All single height boards MUST be designed according to the dimensions given in 
Figure 7-2. 

RULE 7-6: 

The hole pattern for the 96 pin 603-2-IEC-CO96Mx-xxx P1 connector MUST be as 
shown in Figure 7-2. 

SUGGESTION 7.1: 

Use the PC layout grid shown in Figure 7-2. 

OBSERVATION 7.4: 

Modular front panel hardware is available from several manufacturers which, when 
mounted on the grid shown in Figure 7-2, properly aligns with the front panel grid 
shown in Figure 1-1. 

PERMISSION 7.4: 

Components, other than the 603-2-IEG-CO96Mx-xxx connector, MAY be placed in 
such a way that they do not align with the grid pattern. 

7.2.2 Double Height Boards 

OBSERVATION 7.5: 

A double height VMEbus board is 233.35mm (9.187 inch) high and 160 mm (6,299 
inch) deep with an area of approximately 373.4 sq. cm (57.9 sq. inch). 

RULE 7.7: 

All double height boards MUST be designed according to the dimensions given in 
Figure 7-3. 

RULE 7.8: 

The hole pattern for the 96 pin 603-2-IEC-CO96Mx-xxx PI connector MUST be as 
shown in Figure 7-3. 

RULE 7.9: 

IF a 96 pin 603-2-IEC-CO96Mx-xxx connector is used for P2, 

THEN its hole pattern MUST be as shown in Figure 7-3. 

OBSERVATION 7.6: 

As in the case of the single height boards above, the grid shown in Figure 7-3 properly 
aligns modular front panel components with the front panel grid shown in Figure 7-8. 

PERMISSION 7.5: 

Components, other than the 603-2-IEC-xxxxxx-xxx connectors, MAY be placed m 
such a way that they do not align with the grid pattern. 
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OBSERVATION 7.7: 

There is a discontinuity of 1.27mm (0.05 inch) between the 2.54 (0.10 inch) arid 
patterns for the upper and lower half of the board. 

7.2,3 Board Connectors 

The single height board has only one connector on its back edge. It Is called the PI 
connector. A double height board has either one or two connectors on its back edae 
If It has one connector, that connector is called the PI connector and is located on the 
upper half of the back edge, if it has two connectors the upper one is called the PI 
connector and the lower one is called the P2 connector. 

RULE 7.10: 

The PI and P2 connectors of all VMEbus boards MUST meet or exceed the 
mechanical specifications of a 603-2-IEC-C096Mx-xxx class 2 connector and MUST 
be mounted as shown in Figure 7-4. 

OBSERVATION 7.8: 

603-2-IEC class 2 connectors have a minimum mechanical endurance of 400 
insertion/extraction cycles. 

OBSERVATION 7.9: 

The symmetry symbol in the box below each board outline in Figure 7-4 sets an upper 
imit on how much the connector's center line can be tilted with respect to the board's 
I lower edge. This limit is described in the following rule. 

BRULE 7.11: 
I*?«5M'S^'V!i^i'^';.?'^*^"°® ^^^'> ^^°'" ^^^ '^°^''d's lower edge to the point A in Figure 
S n. o • ux °^ ^'"®'' '*^ perpendicular distance (d2) to point B by more than 0.3 mm 
(0.012 inch). 

RULE 7.12: 

IF a VMEbus board is designed to use the center row of P2 for address or data 

bus expansion, or the board requires more power than the PI connector can 
provide, 

THEN a 96 pin 603-2-IEC-CO96Mx-xxx P2 connector MUST be provided and it 
MUST be mounted as sTiown in Figure 7-4. 

PERMISSION 7.6: 

Where neither address nor data bus expansion is required, and where the board does 
not require more power than the PI connector can provide, any 603-2-IEC-xxxxxx-xxx 
connector MAY be used for P2 on a double height VMEbus board or the board MAY 
be designed without a P2 connector. 

PERMISSION 7.7: 

On double height boards, th© two outside rows of pins on the P2 connector MAY be 
used to provide user defined connections (See Section 7.6.2). 
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PERMISSION 7.8: 

I/O cables MAY be connected to the front edge of a VMEbus board. No connectors are 
prescribed for these cable connections. 

SUGGESTION 7.2: 

Where possible, avoid the use of cable connections to the front edge of VMEbus 
boards. This makes it much easier to install and remove boards from the subrack 
during maintenance. 

7.2.4 Board Assemblies 

The board assembly typically consists of a PC board, as defined above with either one 
or two 603-2-1 EC-xxxxxx-xxx connectors affixed to the board's back edge, electronic 
components, and an optional front panel with handles. For more detail on the front 
panels see Section 7.3. 

RULE 7.13: 

Solder filets, tracking, and components on VMEbus boards MUST NOT be closer 
than 2.5mm (0.098 inch) from the top and bottom edges of the board to guarantee 
clearance between them and the board guides. Figure 7-2 and Figure 7-3 show these 
dimensions. 

Figure 7-5 shows a cross sectional view of a PC board, its front panel, its connector 
and the backplane. The dimensions given are nominal values and are based upon 
the dimensions given in the other drawings in this chapter. 

7.2.5 Board Widths 

PERMISSION 7.9: 

VMEbus boards MAY be designed to occupy more than one slot. 

VMEbus boards designed to occupy a single slot of the subrack are called single width 
boards. 

7.2.6 VMEbus Board Warpage, Lead Length and Component Height 

During the manufacturing process boards sometimes become warped. 

RULE 7.14: 

The sum of warpage and component lead length MUST be less than or equal to 2.47 
mm (0.097 inch) from where the solder side of an ideal (unwarped) board would be, 
and the sum of component height and warpage (in the other direction) MUST be less 
than or equal to 13.71mm (0.54 inch) plus an integral multiple (N) of 20.32mm (0.8 
inch), from where the component side of an ideal (unwarped) board would be. (Where 
N = the number of slots that the board occupies minus 1 .) 
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OBSERVATION 7.10: 

During insertion into the subracl<, the component leads of a board might contact the 
nght edge of the front panel to its left. For this reason, the board should be inserted 
carefully to avoid bending the component leads. 

SUGGESTION 7.3: 

Where possible, trim the component lead lengths to 1.52 mm (0.06 inch). This makes 
mstallation and renioval of boards more convenient. Since the maximum allowable 
warpage IS affected by the length of these component leads, trimming them allows 
boards with larger warpage to meet the specifications. 

OBSERVATION 7.11: 

The dimensions given in SUGGESTION 7.3 ensure that there will be a clearance of at 
east 2.54 mm (0.1 inch) between components of each board and the component 
leads of he board to its right. This space allows adequate air flow and prevents 
additional warpage and vibration from causing interboard contact. 

RULE 7.15: 

All VMEbus boards MUST be measured, after they are assembled, to ensure that the 
combination of board warpage, component lead length, and component height do not 
exceed the specified limits when the board is inserted into a subrack. In order to 
properly make these measurements, the board MUST be placed in a subrack (or a 
similar test fixture) while the measurements are taken. 

rSi^K® '^f ^'^^^^ ^^°^^^ (^'"9'® °'' ^°"'^'® f^^'S^^t) i" a subrack, and shows how the 
combination of board warpage, component lead length, and component height are to 
be measured. The interboard separation planes defined in that Figure provide the 
reference from which the measurements are made a k 



n OBSERVATION 7.12: 



A special test fixture, which simulates a subrack, is helpful in speeding ud the 
measurements shown in Figure 7-6. vj ,y u^; me 

7.3 FRONT PANELS 

This section provides the mechanical specifications for the single and double heiqht 
board front panels and associated hardware. 

PERMISSION 7.10: 

VMEbus boards MAY be manufactured with or without front panels. 

RECOMMENDATION 7.2: 

Use front panels and associated hardware to prevent VMEbus boards from vibratina 
out of the subrack, and to guide airflow through the subrack. 
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RULE 7.16: 

IF front panels are used, xu * -j t,^**^^ r.t 

THEN screws MUST be provided on those panels to secure the top and bottom of 

the panels to the subrack, and their screw threads MUST be M2.5 X 0.45 

pitch (see Figure 7-7). 

Fiqure 7-7 shows a single height, single width front panel. Figure 7-8 shows a double 
height, single width front panel. The grid format on the rear face of these front panels 
are aligned with the board grids in Figure 7-2 and Figure 7-3 respectively. 

Install front panel components such as Light Emitting Diodes (LEDs) and switches so 
that their centers are aligned with a front panel grid point. 

7.3.1 Handles 

The VMEbus board" designer MAY design VMEbus boards front panels with or without 
handles. 

RECOMMENDATION 7.3: . .u u ^ 

Provide handles to make VMEbus boards easier to remove from the subrack. 



I 



OBSERVATION 7.13: ^^, „ ^u,or,^ 

The handles available from various manufacturers vary somewhat m overall shape. 

SUGGESTION 7.5: ^ ■ r-- H 

Choose handles whose depth and height conform to the dimensions shown in Figure K 

7-7 and Figure 7-8. HH 

RECOMMENDATION 7.4: 

When mounting handles on VMEbus board front panels, choose one or more of the 
locations shown in Figure 7-7, Figure 7-8, Figure 7-11 and Figure 7-12. 

On single height "bo"ards, handles MAY be installed in any of the following 
combinations: 

1 . Top only 

2. Bottom only 

3. Top and bottom 
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PERMISSION 7.13: 

?omb1natilfns:''^'* boards handles MAY be installed in any of the following 

1. Top only 

2. Middle only 

3. Bottom only 

4. Top and middle 

5. Bottom and middle 

6. Top and bottom 

OBSERVATION 7.14: 

OBSERVATION 7.15: 

Removal of double height boards that have both a P1 and a 96-oin p? rnnn»ot„. 

7.3.2 Front Panel Mounting 

RECOMMENDATION 7.5: 

IF front panels are used, 

THEN keep the reserved areas shown in Figure 7-9 and Fiaure 7-10 frp*. of 

It?pT>2f *' *2 f "°^ ^^-^ '"^*^"^*'°" °f font panermounting^KScke ts Locate 
tjie holes used to mount these brackets as shown in Figure 7-fand Figure 7 
RECOMMENDATION 7.6: 
VLcM f°"tP^"6's are used on double height boards, 

RULE 7.17: 

IF front panels are used, 

THEN the test dimension shown in Figure 7-9 and Figure 7-10 from the rear farp nf 
the front panel to the rear face of the connecto?, MUST be maimlined 

OBSERVATION 7.16: 
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7.3.3 Front Panel Dimensions 

All dimensioning of the front panel is done from a datum point 0.15 mm (0.006 inch) to 
the left of its top left corner as viewed from the front. 

RULE 7.18: ^ . ^. ., -, 

Single width front panels MUST be designed to the dimensions shown in Figure 7-7 

and Figure 7-8. 

RECOMMENDATION 7.7: 

Make front panels 2.5mm (0.098 inch) nominal thickness. 

OBSERVATION 7. 17: 

The 20 02 mm (0.788 inch) width of the single slot front panels is 0.30 mm (0.012 inch) 
narrower than the 20.32 mm (0.8 inch) slot spacing. This prevents mechanical 
interference between adjacent front panels due to tolerances in the board assemblies 
and subracks. 

RULE 7.19: ^' . ' , 

IF a board occupies more than one slot and has a front panel, 

THEN the width of that front panel MUST be 20.02 mm (0.788 inch) plus an integral 

multiple (N) of 20.32mm (0.8 inch), where N is the number of slots that the 

board occupies. 

Single slot front panels MUST be equipped with one fastener at the top and another 
at the bottom, located as shown in Figure 7-7 and Figure 7-8. 

7.3.4 Filler Panels 

Filler panels are sometimes used where the backplane positioning leaves a gap on 
the left or right end of the subrack's front panel or where there are empty slots. These 
filler panels require no mounting brackets because they are not attached to pnnted 
circuit boards. They are secured to the subrack by screws or quarter-turn fasteners on 
their top and bottom ends like the front panels of VMEbus boards. 

RULE 7 21 ■ 

Filler panels MUST be designed to conform to the dimensions given in Figure 7-1 1 

and Figure 7-12. 

RULE 7 22" 

Single slot filler panels MUST be equipped with one fastener at the top and another 
at the bottom, located as shown in Figure 7-1 1 and Figure 7-1 2. 

RECOMMENDATION 7.8: . ,, .^.. .. 

Use filler panels on VMEbus based systems to maintain proper air flow within the 
subrack and to improve the appearance of the assembled VMEbus system. 
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MECHANICAL SPECIFICATIONS 
SUGGESTION 7.6: 

SUGGESTION 7.7: 

7.3.5 Board Ejectors / Injectors 
OBSERVATION 7.18: 

OBSERVATION 7.19: 

S NtloSfblr"" '°' ^ ''"^'" 603-2-'EC-CO96Mx-xxx connector can be as high as 

PERMISSION 7.14: 
7.4 BACKPLANES 

;nH?.wl K ^L * ■''^ ^^ *'^® ^2 connector pins, allowing the two outer rows frows a 
and c) to be used to implement the VMXbus or for any other user defined functions? 

n?^Ji^fT T ^^signated 1 . 2, 3,... 21 , with the slot numbering starting at the left end 
an?g7ef tofi "' '""'' ''°"' ''' ^^°"*- '''' ^^'^^-^^^'^ propa^llfoTsirtV with sloT? 

RULE 7.23: 
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MECHANICAL SPECIFICATIONS 

RULE 7-24: 

When a J2 backplane is used to provide for 32 bit wide address and data transfers, it 
MUST bus all pins of the center row (row b) of those slots for which it has connectors. 
(See Section 7.6.2) 

RULE 7 25: 

The 96 pin 6"o3-2-IEC-C096Fx-xxx connectors MUST be used on all J1 VMEbus 
backplanes and on all J2 expansion backplanes. 

RULE 7 26: 

All VMEbus J1 backplanes MUST have some provision for jumpering the interrupt 
acknowledge and bus grant daisy-chains when boards are not plugged into a slot. 

SUGGESTION 7.8: ^. ^. ^ao o icr- 

To provide for the jumpering of the J1 backplane daisy-chains, use 603-2-IEC- 
C096FX-XXX connectors that have wire-wrap pins. 

SUGGESTION 7.9: 

IF J1 connectors without wire-wrap pins are used, ^ 

THEN place all of the jumper pins for daisy-chains next to the J1 connector that they 
are jumpering. 

PERMISSION 7.15: . . . * . ^u * 

As long as all other requirements are met, and proper spacing is maintained between 
the J1 and J2 connectors, the J1 and J2 backplanes MAY be designed as a single PC 
board. 

SUGGESTION 7.10: ... * ,o HI 

Use 603-2-1EC-CO96FX-XXX connectors with wire-wrap pins for the connectors on J^ K 

backplanes. This allows attachment of ribbon cables and secondary backplanes to H 

those pins. ^* 

7.4.1 Backplane Dimensional Requirements 

Figure 7-13 depicts a 21 slot backplane. Figure 7-14 shows where optional threaded 
studs can be provided to connect DC power cables to the backplane. 

PERMISSION 7.16: 

VMEbus backplanes MAY be designed with up to 21 slots. 

RECOMMENDATION 7.9: , ^ .^^^ 

When designing a backplane with fewer than 21 slots, make the width 

(Nx20.32mm)-1.44mm, +0/-0.3mm 

where N is the number of slots. This allows two backplanes to be installed next to 
each other without wasting a slot position in the subrack. 
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MECHANICAL SPECIFICATrONS 

RECOMMENDATION 7.10: 

Do not design backplanes with widtlis greater than 425 28mm Mfiy^-? ■,nr^h\ 
Backplanes longer than this might not fit into widelj aSbfl subracks/ "'^• 

PERMISSION 7.17: 
RULE 7.27: 

OBSERVATION 7.20: 

The backplane dimensions shown in Figure 7-14 repeat every 20.32mm (0.8 inch). 

7.4.2 Signal Line Termination Networks 

RULE 7. 28: 

som?wav''fo'Snnf^ ""."^^ ^'^^^'. ^^"^ ''""^-'" terminations or they MUST provide 
SttS°SeX^?6%;°d"?eS^^^^^^^^^^^ for terminating all o^he sign^a.rel 

PERMISSION 7.18: 

Il!®i!'^J"^* k" °''''°"'"*'y ""^^ ®'t'^®'' be built onto the ends of the backolane or it MAY 

IgXSSl?e1S^^%:„r"^ ''^' *• """' «''"- "^ '-< ^^e"Lro?fhI 
RULE 7.29: 

Ka'i§Sf(2aS1nc^^^^^^^^ ^'' P'"3-°" *^^'"'"^*°^ ^°^^^^' "^"ST NOT 

OBSERVATION 7.21: 

In? S?pr v"^'"^ '"'^*^ °' ^ 2^ ®'°* Vl^^bus backplane is required to accomodate the 
L^edeff^rtuTaTac^^^^^^^^^^^ P'"^-°" ^--■"'^^ -^"'- -^S^aHy 

7.5 ASSEMBLY OF VMEbus SUBRACKS 

l^BUom^l f^n^L^riZn^^^l!^ ^''^l^''^^ ^'^ assembled. All horizontal dimensions 
are trom the left hand edge of the front opening of the subrack. 

7.5.1 Subracks And Slot Widths 

Figure 7-1 5 shows a typical double height 21 -slot subrack. 
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MECHANICAL SPECIFICATIONS 

PERMISSION 7.19: . . . ' .u .-aw u 

Double height subracks MAY be used to house double height boards or they MAY be 
sub-divided by the installation of a bracket, into two single height sections, one above 
the other. 

OBSERVATION 7.22: .^ ^ , 

The bracket allowed in PERMISSION 7.19 provides two board guides: the lower guide 
for the board above it and the upper guide for the board below it. 

SUGGESTION 7.11: ^ ^ . ■ ,. . 

Where possible, install the left-most (slot 1) board guides so that their center line is 
3.27mm (0.129 inches) from the left end of the rack opening. This provides sufficient 
clearance for the component leads of the board installed in that slot, and doesn't waste 
any horizontal space. (If this board guide is installed farther to the right there will not 
be room for 21 slots.) 

7.5.2 Subrack Dimensions 

RULE 7. 30: 

All double height VMEbus subracks MUST meet all of the dimensional requirements 
given in Figure 7-15, except for the width dimension, which varies according to how 
many slots are in the subrack. 

RULE 7.31: . , 

All single height VMEbus subracks MUST meet all of the dimensional requirements 
given in Figure 7-15, except for the width dimension, which varies according to how 
many slots are in the subrack, and the vertical distance between the lower and upper 
board guides, which is 100.2 mm, +0.4/-0.0 mm instead of 233.55 mm. 

OBSERVATION 7.23: / ^^^ ^ , , 

The dimension from the front panel mounting surface to the front face of the backplane 
is particularly critical, since it guarantees correct connector engagement. 
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COMPONENT SIDE 
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DOUBLE 
HEIGHT 
BOARD 
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PI AND P2 
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I/O CONNECTORS 



Figure 7-1. Subrack With Mixed Board Sizes 



MECHANICAL SPECIFICATIONS 



160 



- (6.299 



+0 

-0.3 

+0 



- 0.012) 



61 GRID POSITIONS AT 

2.54 (0.1) INTERVALS 

= 152.4 (6.0) 



5.3 (0.209) 



2.76 (0.109) 




-0.012) 



2.7 ±0.1 DIAMETER 
(0.10610.004) 



« — 2.5 (0.098) 



Z7 10.1 DIAMETER 
(0.10610.004) 



NOTES: 

1. All dimensions are shown in millimeters. Inch dimensions are shown in 

2. TheTe grids are provided to help the board designer to align components with the 
front panel grid. 

3 RULE 7.32: 
' Boards MUST be 1 .6 ±0.2 mm (0.063 ±0.008 inch) thick in the guide area. 



B 



Figure 7-2. Single Heiglit Board: Basic Dimensions 
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MECHANICAL SPECIFICATIONS 



3.57 
(0.140) 



I 




0.012) 



2.7 ±0.1 DIAMETER 
(0.10610.004) 



Inch dimensions are shown in 



NOTES: 

1. All dimensions are shown in millimeters 
parentheses. 

^' fram paSgrid^ '"'°''"'^'' *° "^'^ *^^ ^°^'''^ designer to align components with the 
3. RULE 7.33: 

Boards MUST be 1 .6 ±0.2 mm (0.063 ±0.008 inch) thick in the guide area. 

Figure 7-3. Double Height Board: Basic Dimensions 
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MECHANICAL SPECIFICATIONS 




BOTTOM EDGE OF BOARD 
I d1-d2 I ^0.3 mm (0.012 in) 



<l- 



I 



(SEE DETAIL "A") 



T 



0.3 
(0.012) 



nn n 



E] A 



(SEE DETAIL "A") 



^ 



® 



^ +0.002 
-0) 



gir^ 



5N 



ALIGNMENT 
FACES 



133.35 + 0.1 
(5.25 + 0.004) 



85.2 
(3.354 



+0.008 
0) 



^J-J 



ALIGNMENT 
FACES 



50.0 + 0.1 
(1.969 + 0.004) 



W^ 



I 



85.2 J 
(3.354*' 



feH 



ALIGNMENT 
FACES 

/ 



50.0 + 0.1 
(1.96910.004) 



NOTE: All dimensions are shown in millimeters. Inch dimensions are shown in 
parentheses. 



Figure 7-4. Connector Position On Single And Double Height Boards 
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MECHANICAL SPECIFICATIONS 



-• 2 X 2.54 = 5.08 (0.2) 



FIXED CONNECTOR 
MOUNTING PLANE 



I 



FRONT ATTACHMENT PLANE 



INTERBOARD SEPARATION PLANE 




FIXED CONNECTOR 



FREE CONNECTOR 



NOTES: 



1. Fo^r additional information regarding the allowed thickness of boards, see Section 
^' Sard ■^'^ "^"^ ^°'^^° '"^ dimension is the same regardless of the thickness of the 

Figure 7-5. Cross Sectional View of board, Connector. Backplane, And Front Panel 
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MECHANICAL SPECIFICATIONS 
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FRONT VIEW 



SEE NOTE 2 * 
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(0.129) " 



I 2.54 (0.1) — 

SEE NOTE 4 






- n X 20.32 (0.8) »- 



L 3.27 (0. 

I SEE NO 



.129) 
SEE NOTE 3 



•• nx 20.32 (0.8)- 



AAA 

INTERBOARD SEPARATION PLANES 



NOTES: 




2.54 (( 

SEE NOTE 4 

— 3.27 

(0.129) 



(0.1) J V* 2.54(0.1)— » 

lOTE 4 ' 



— 3.27 (0.129) 
SEE NOTE 3 



A A 

INTERBOARD SEPARATION PLANES 



A 
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Inch dimensions are shown in 



1. All dimensions are shown in millimeters, 
parentheses. 

2. SUGGESTION 7,12: ^^ ^^ . ^^ 

Trim component lead lengths to no more than 1.52 millimeters (0.06 mch). 

3 RULE 7-34: 

Component leads and components mounted on the solder side of the board 
MUST NOT protrude through the interboard separation plane after it has been 
completely seated in the backplane. 

Components "mounted on the component side of the board MUST NOT be any 
closer than 2.54 millimeters (0.1 inch) to the interboard separation plane after it has 
been completely seated in the backplane. 



Figure 7-6. Component Height, Lead Length And Board Warpage 
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MECHANICAL SPECIFICATIONS 



7.62 
(0.118) ~| (0.3) 
NOTE 3 



I 




31 GRID POSITIONS AT 

2.54 (0.1) INTERVALS = 

76.2 (3.0) 



NOTES: 

^' ^'rentS°"^ ^'^ ^''°"'" '" "'"""'^*®''S- '"^^^ dimensions are shown in 

i RK^MMlgDrTloN '''5!^ "'P^' °' '"""^^ ^'' ^"39^^*'°"^ °"'y- 

P°ERMISSIOn''"*7^20°'^ ^'^^ ""^ ^°"^ '"^ *''°"' *^® interboard separation plane. 
Iep\rafonSe'^°'^ '^'^^ ^^ '°'^*''' ^^'^ """ ^^"^ '"^ ^'^'^ *^^ interboard 



Figure 7-7. Single Height, Single Width Front Panel 
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MECHANICAL SPECIFICATIONS 



31 GRID POSITIONS AT 
: 4- 2-5* (0-1) INTERVALS = 
7$.2 (3.0) 




K 

RESERVED AREA FOR 

MOUNTING BRACKETS 

(2, 3 OR 4 PLACES) 



I 



NOTES: 

1. All dimensions are sliown in millimeters, incli dimensions are shown in 

parentheses. 

2. Dimensions given for height and depth of handles are suggestions only. 

3. RECOMMENDATION 7.12: 

Locate the mounting hole 7.62 mm (0.3 in) from the interboard separation plane. 
PERMISSION 7.21: _ u . u ^ 

The mounting hole MAY be located 12.7 mm (0.5 in) from the interboard 
separation plane. 

Figure 7-8. Double Height, Single Width Front Panel 
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MECHANICAL SPECIFICATIONS 



^6.0 

* (0.236)" 

2.54 
(0.1)" 



7.0 
(0.276)" 



I 



RESERVED AREA 
FOR BOARD 
MOUNTING 



2.5 (0.098) 



>81.28 
(3.2) 



2.5 (0.098) 



TEST DIMENSION 

169.93 + 0.4 

(6.690 + 0.015) 



^ 



±J 



NOTE: 

parentheser^'°"^ ^'^ ^^°'^" '" millimeters. Inch dimensions are shown in 

Figure 7-9. Front Panel Mounting Brackets And Dimension Of Single Height Boards. 
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MECHANICAL SPECIFICATIONS 



RESERVED AREA 
FOR BOARD 
MOUNTING 




TEST DIMENSION 

169.93 ± 0.4 

(6.69010.015) 



Su-' 



g^^ 



133.25 + 0.1 
(5.25 + .004) 



B 



^ 



NOTE: 

1. All dimensions are shown in millimeters. Inch dimensions are shown in 
parentheses. 

Figure 7-10. Front Panel Mounting Brackets And Dimension Of Double Height Boards. 
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MECHANICAL SPECIFICATIONS 



n X 5.08 (MAX. 84 x 5.08) 
(n X 0.2 (MAX. 84 x 0.2) 



B 




NOTES: 

1. All dimensions are shown in millimeters. Inch dimensions are shown in 
parentheses. 

2. RECOMMENDATION 7.13: 

Where a panel is more than 50.8 millimeters (2.0 inch) wide use at least 4 
mounting holes; two at the top and two at the bottom. 

3. Dimensions given for height and depth of handles are suggestions only. 



Figure 7-11. Single Height Filler Panel 
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MECHANICAL SPECIFICATIONS 



n X 5.08 (MAX. 84 x 5.08) 
n X 0.2 (MAX. 84 x 0.2) 




B 



14.0 
(0.551) 
TYP 



NOTES: 

1. All dimensions are shown in millimeters. Inch dimensions are shown 
parentheses. 

2. RECOMMENDATION 7.14: 

Where a panel is more than 50.8 millimeters (2.0 inch) wide use at least 
mounting holes; two at the top and two at the bottom. 

3. Dimensions given for height and depth of handles are suggestions only. 



in 



Figure 7-12. Double Height Filler Panel 
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FIRST INTERBOARD SEPARATION PLANE 

V 
V 



Direction of daisy-chain propagation 
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7.92 (0.312) - 
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NOTES: 



1. All (jimensions are shown in millimeters. Inch (dimensions are shown in parentheses 

2. Backplane width varies (depen<ding on the number of slots. 



Figure 7-13. Backplane Overall Dimensions 
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7.62 
(0.3) 



>0.72 
"(0.028)" 



122.S I 

(4.823) 



130.010.3 
(5.11810.012) 



<> 



^ 4- -^ 



ABC T 

, +++ + + + 



40.64 _ 
" (1-6) 



60.96 _ 
" (2-4) 



81.28 _ 
~ (3.2) 



101.6 _ 
~ (4.0) 



CONNECTOR SIDE 
(VIEWED FROM FRONT OF SUBRACK) 



2.54 
(0.1) " 



2.54 
(0.1) " 
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j± 4- 



" B 
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21.88 
(0.861) 




16.2 
0.64 

4-r 



16.25 
(0.640) 



A 
A 



RECOMMENDED MOUNTING 

HOLE POSITIONS 

2.710.1 DIAMETER 

(0.10610.004) 



CONNECTOR MOUNTING 
HOLE POSITIONS IF 

REQUIRED 

2.710.1 DIAMETER 

(0.10610.004) 



FIRST INTERBOARD SEPARATION PLANE 



B 



NOTE: 

1. All dimensions are shown in millimeters. Inch dimensions are shown in 
parentheses. 



Figure 7-14. Backplane Detailed Dimensions 



241 



MECHANICAL SPECIFICATIONS 



TERMINATOR BOARD 



BACKPLANE 



96-WAY CONNECTOR 




REVERSE lEC SHELL MOULDING 



I 



BACKPLANE 



96-WAY CONNECTOR 




TERMINATOR BOARD 



REVERSE lEC SHELL MOULDING 

n In n ^ elIdlI 



Figure 7-15. "Off-Board Type" Backplane Termination 
(Viewed From Top Of Backplane) 
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MECHANICAL SPECIFICATIONS 



BACKPLANE 



TERMINATORS 




E 



96-WAY CONNECTOR 



Figure 7-16. "On-Board Type" Backplane Termination 
(Viewed From Top Of Backplane) 
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FIRST INTERBOARD SEPARATION PLANE 

V 
V 



FRONT PANEL 
MOUNTING SURFACE 



WORKING APERTURE 



2 0R4SUBRACK 
MOUNTING POSITIONS 



NOTES: 



SEE FIGURE 7-18 
FOR BOARD GUIDE DETAIL 
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RIGHT SIDE VIEW 



FIRST INTERBOARD SEPARATION PLANE 



1. All dimensions are shown in millimeters. Inch dimensions are shown in parentheses. 

2. RULE 7.36: 

The thickness of the insulation spacer (shown in the right side view) MUST be chosen 

to assure that the face of the backplane is the correct distance from the front panel mountinq surface. 

OBSERVATION 7.24: 

The thickness of the spacer specified in RULE 7.36 may vary from one vendor to another. 

3. PERMISSION 7.22: 

Side plates MAY be extended to the rear as required. 

4. For additional information, see lEC 297-1 and lEC 297-3. 



Figure 7-17. 21 Slot Subrack 
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MECHANICAL SPECIFICATIONS 



SINGLE HEIGHT 



BOARD GUIDE 




HORIZONTAL MEMBER 



^2.0 (.079) 

^6.0 (0.236) 



INTERBOARD SEPARATION PLANE 



V 



DOUBLE HEIGHT 



245.35 
(9.659) 



uhj- 



-H 



233.55 



(9.195 



+0.4 

-0 

+0.016 



HORIZONTAL MEMBER 
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, 10.16 
' (0.40) 
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Figure 7-18. Board Guide Detail 
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MECHANICAL SPECIFICATIONS 

7.6 VMEbus BACKPLANE CONNECTORS AND BOARD CONNECTORS 
7.6.1 Pin Assignments For Ji/pi Connectors 

Table 7-1 provi0es signal names for the J1/P1 connector pins. (The connector 
consists of three rows of pins labeled rows a, b, and c.) i me connector 



Table 7-1. J1/P1 Pin Assignments 



I 



PIN 
NUMBER 



ROWa 

SIGNAL 

MNEMONIC 



1 


DOO 


2 


D01 


3 


D02 


4 


D03 


5 


D04 


6 


D05 


7 


D06 


8 


DO 7 


9 


GND 


10 


SYSOLK 


11 


GND 


12 


Dsr 


13 


DSO* 


14 


WRITE* 


15 


GND 


16 


DTACK* 


17 


GND 


18 


AS* 


19 


GND 


20 


lACK* 


21 


lACKIN* 


22 


lACKOUr 


23 


AM4 


24 


A07 


25 


A06 


26 


A05 


27 


A04 


28 


A03 


29 


A02 


30 


A01 


31 


-12V 


32 


+5V 



ROWb 

SIGNAL 

MNEMONIC 



ROWc 

SIGNAL 

MNEMONIC 



BBSY* 


DOS 


BCLR* 


D09 


ACFAIL* 


D10 


BGOIN* 


D11 


BGOOUT* 


D12 


BG1IN* 


D13 


BG10UT* 


D14 


BG2IN* 


D15 


BG20UT* 


GND 


G3IN* 


SYSFAIL* 


BG30UT* 


BERR* 


BRO* 


SYSRESET* 


BR1* 


LWORD* 


BR2* 


AM5 


BR3* 


A23 


AMO 


A22 


AMI 


A21 


AM2 


A20 


AM3 


A19 


GND 


A18 


SERCLK(I) 


A17 


SERDAT*(1) 


A16 


GND 


A15 


IRQ7* 


A14 


iRQ6* 


A13 


IRQ5* 


A12 


IRQ4* 


All 


IRQ3* 


A10 


IRQ2* 


A09 


IRQ1* 


A08 


+5VSTDBY 


+12V 


+5V 


+5V 



Note: (1): See Appendix for further information on the use of these signals 
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7.6.2 Pin Assignments For The J2/P2 Connector 

Table 7-2 provides signal names for the J2/P2 connector pins, 
consists of three rows of pins labeled rows a, b, and c.) 



(The connector 



Table 7-2. J2/P2 pin assignnnents 





ROWa 


ROWb 


ROWc 


PIN 


SIGNAL 


SIGNAL 


SIGNAL 


NUMBER 


MNEMONIC 


MNEMONIC 


MNEMONIC 


1 


User Defined 


+5V 


User Defined 


2 


User Defined 


GND 


User Defined 


3 


User Defined 


RESERVED 


User Defined 


4 


User Defined 


A24 


User Defined 


5 


User Defined 


A25 


User Defined 


6 


User Defined 


A26 


User Defined 


7 


User Defined 


A27 


User Defined 


8 


User Defined 


A28 


User Defined 


9 


User Defined 


A29 


User Defined 


10 


User Defined 


A30 


User Defined 


11 


User Defined 


A31 


User Defined 


12 


User Defined 


GND 


User Defined 


13 


User Defined 


+5V 


User Defined 


14 


User Defined 


D16 


User Defined 


15 


User Defined 


D17 


User Defined 


16 


User Defined 


D18 


User Defined 


17 


User Defined 


D19 


User Defined 


18 


User Defined 


D20 


User Defined 


19 


User Defined 


D21 


User Defined 


20 


User Defined 


D22 


User Defined 


21 


User Defined 


D23 


User Defined 


22 


User Defined 


GND 


User Defined 


23 


User Defined 


D24 


User Defined 


24 


User Defined 


D25 


User Defined 


25 


User Defined 


D26 


User Defined 


26 


User Defined 


D27 


User Defined 


27 


User Defined 


D28 


User Defined 


28 


User Defined 


D29 


User Defined 


29 


User Defined 


D30 


User Defined 


30 


User Defined 


D31 


User Defined 


31 


User Defined 


GND 


User Defined 


32 


User Defined 


+5V 


User Defined 



I 



247 



MECHANICAL SPECIFICATIONS 



I 



248 



APPENDIX A 
GLOSSARY OF VMEbus TERMS 



A16 

A type of module that provides or decodes an address on address lines A01 

through A15. 

A24 

A type of module that provides or decodes an address on address lines A01 

through A23. 

A32 

A type of module that provides or decodes an address on address lines A01 

through A31 . 

ARBITRATION 

The process of assigning control of the DTB to a REQUESTER. 

ADDRESS-ONLY CYCLE ^ ^ ^, ^^,^^ 

A DTB cycle that consists of an address broadcast, but no data transfer. SLAVEb 
do not acknowledge ADDRESS-ONLY cycles and MASTERS terminate the cycle 
without waiting for an acknowledgment. 

ARBITER ^^^..r-o^r-o 

A functional module that accepts bus requests from REQUESTER modules and 
grants control of the DTB to one REQUESTER at a time. 

ARBITRATION BUS , ^^. ^ 

One of the four buses provided by the VMEbus backplane. This bus allows an 
ARBITER module and several REQUESTER modules to coordinate use of the DTB. 

ARBITRATION CYCLE ^ ^ _ 

An ARBITRATION CYCLE begins when the ARBITER senses a bus request. The 
ARBITER grants the bus to a REQUESTER, which signals that the DTB is busy. The 
REQUESTER terminates the cycle by releasing the bus busy signal which causes 
the ARBITER to sample the bus requests again. 

BACKPLANE (VMEbus) . . , *u *h.* k... +h^ 

A printed circuit (PC) board with 96-pin connectors and signal paths that bus the 
connector pins. Some VMEbus systems have a single PC board, called the J 1 
backplane. It provides the signal paths needed for basic operation. Other VMEbus 
systems also have an optional second PC board, called a J2 backplane It 
provides the additional 96 pin connectors and signal paths needed for wider data 
and address transfers. Still others have a single PC board that provides the signal 
conductors and connectors of both the J1 and J2 backplanes. 
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B BACKPLANE INTERFACE LOGIC 
Special interface logic that takes into account the characteristics of the backolanp- 
TJS^rlT '"^P^d^"^^' propagation time, termination 3^6?^ The 5me^^^^^^ 
specification prescnbes certain rules for the design of this loaic basid on thp 
maximum length of the backplane and its maximum number^ board slote 

BLOCK READ CYCLE 

A DTB cycle used to transfer a block of 1 to 256 bytes from a SLAVE to a MASTER 

tTaSSI^IL'rte? the"&?lR ? °^ ' ' f ' T ' 4 ^^*^ tranffers^'oncete'block 
bSn t ansferrPH it ^«!Jc ? ^""^^ not release the DTB until all of the bytes have 
oeen transferred. It differs from a stnng of read cycles in that the MASTFR 

Th°e'n ?hf ?i°Atp°"' ^'^^'^^ ^"' address modifier (at the beginning of the cyde) 
Then the SLAVE increments this address on each transfer so that the da a for hi 
next cycle is retrieved from the next higher location. tne data for the 

BLOCK WRITE CYCLE 

iP^^, ^\^^^ H^^^ *° transfer a block of 1 to 256 bytes from a MASTER to a SLAVF 

L ! hvtf H^"*". '^"f '" ""^ ^'''^"^'' *° '^^ b'°^k r^^d cycle ifuses a s^?ing oM I 
Svtt^hLt? ^'■^"ff^'-s and the MASTER does not release the DTB un UI°of the 
MA^tfI hrofn " transferred. It differs from a string of write cycles nth a thi 
MASTER broadcasts only one address and address modifier (at the beainnina of 
nL?r^^\ ^''^': ^l^!, SLAVE increments this address on each transfer so "hShe 
next transfer is stored in the next higher location. ifcinsTer so tnat the 

BOARD 

A printed circuit (PC) board, its collection of electronic components and either one 
or two 96 pm connectors that can be plugged into VMEbus LcMane connected 

BUS TIMER 

A functional module that measures how long each data transfer takes on thP otr 

MAS^R^£Vo^'ri'nl?'H''f 'I " ''T''' *" '^^ ^°° '°"9- wShTut th^'mSSue' iHhe 
MAb I ER tnes to transfer data to or from a non-existent SLAVE location it could wait 

forever for a SLAVE to respond. The BUS TIMER prevents this bf telminatilgThe 

D08(O) 

A SLAVE that sends and receives data 8 bits at a time over D00-D07 

OR ' 

an INTERRUPT HANDLER that receives 8 bit STATUS/ID's over D00-D07 

OR 

an INTERRUPTER that sends 8 bit STATUS/ID's over D00-D07. 

D08(EO) 

A MASTER that sends or receives data 8 bits at a time over either D00-D07 or D08- 

OR 
a SLAVE that sends and receives data 8 bits at a time over either D00-D07 or D08- 



D15. 
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D16 

A MASTER that sends and receives data 16 bits at a time over D00-D15, 

OR 
a SLAVE that sends and receives data 16 bits at a time over D00-D15, 

OR 
an INTERRUPT HANDLER that receives 16 bit STATUS/ID's over D00-D15. 

OR 
an INTERRUPTER that sends 16 bit STATUS/ID's over D00-D15. 

D32 

A MASTER that sends and receives data 32 bits at a time over D00-D31 , 

OR 
a SLAVE that sends and receives data 32 bits at a time over D00-D31 , 

OR 
an INTERRUPT HANDLER that receives 32 bit STATUS/ID's over D00-D31 , 

OR 
an INTERRUPTER that sends 32 bit STATUS/ID's over D00-D31 . 

DAISY-CHAIN ,, ,, 

A special type of VMEbus signal line that is used to propagate a signal level from 
board to board, starting with the first slot and ending with the last slot. There are 
four bus grant daisy-chains and one interrupt acknowledge daisy-cham on the 
VMEbus. 

DATA TRANSFER BUS _ ^^ r^A-^A ™AMoirtro 

One of the four buses provided by the VMEbus backplane. The DATA TRANSFER 
BUS allows MASTERS to direct the transfer of binary data between themselves 
and SLAVES. (DATA TRANSFER BUS is often abbreviated DTB.) 

DATA TRANSFER BUS CYCLE 

A sequence of level transitions on the signal lines of the DTB that result in the 
transfer of an address or an address and data between a MASTER and a SLAVE. 
There are 34 types of data transfer bus cycles. 

DTB 

An acronym for DATA TRANSFER BUS. 

FUNCTIONAL MODULE 

A collection of electronic circuitry that resides on one VMEbus board and works 
together to accomplish a task. -^ 

lACK DAISY-CHAIN DRIVER , ^ ^ . 

A functional module which activates the interrupt acknowledge daisy-chain 
whenever an INTERRUPT HANDLER acknowledges an interrupt request This 
daisy-chain ensures that only one INTERRUPTER will respond with its STATUS/ID 
when more than one has generated an interrupt request on the same level. 



B 



251 



APPENDIX A 



B INTERRUPT ACKNOWLEDGE CYCLE 
A DIB cycle, initiated by an INTERRUPT HANDLER that reads a "STATliq/in- 
Hptlf: 'NTERRUPTER. An INTERRUPT HANDLERgenerSes th^ cylfe when it 
detects an interrupt request from an INTERRUPTER and it has control of the DTB 

PRIORITY INTERRUPT BUS 

mrlroDlmT m''.i'^!,®^ providod by the VMEbus backplane. The PRIORITY 

KtIrSupt l^ANH 'fp' INTERRUPTER modules to send interrupt requests to 

i\!u . ^ .u"^"^?"-^^ modules, and INTERRUPT HANDLER modules to 

acknowledge these interrupt requests. muauies lo 

INTERRUPTER 

A functional module that generates an interrupt request on the INTERRUPT BUS 

frn'^icf ".P'°^"^®^ STATUS/ID information when the INTERRUPT HANDLER 
r6C|u@sis It. 

INTERRUPT HANDLER 

A functional module that detects interrupt requests generated by INTERRUPTERS 
and responds to those requests by asking for STATUS/ID information^ 

LOCATION MONITOR 

A functional module that monitors data transfers over the DTB in order to detect 
tro'n? n1 hiS! '°'^'°"'h '! '^^- ''^"" ^^^'9"^^ *° ^^t^^- When an access occuS 
board signal ^'^" ''^*'°"^' *^® "-OCATION MONITOR generates an on- 

MASTER 

and f SUVV^SiSuS^* '"'*'^*^^ ^^^ ""^""^^ '" °''^^' *° transfer data between itself 

POWER MONITOR MODULE 

SmfS?' "module that monitors the status of the primary power source to the 
^eaui?pH fnr^fS,^"'' f 3"^'' ''''■®" ^^^ power has%trayed%utside the HmSs 
iSZl Z n ^'"® ^^^*!"' operation. Since most systems are powered by an AC 

READ CYCLE 

A DTB cycle used to transfer 1 , 2, 3, or 4 bytes from a SLAVE to a MASTER The 
fSS Sfiwl''^^" the MASTER broadcasts an address and an address modif er 
Each SLAVE captures this address and address modifier, and checks to see if it is 
on?h?H2?o h ® ""^w '^y" ^°; 'l''e*rieves the data from its internal storage, places it 
on he data bus, and acknowledges the transfer. Then the MASTER terminates the 
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READ-MODIFY-WRITE CYCLE 

A DTB cycle that is used to both read from, and write to, a SLAVE location without 
permitting any other MASTER to access that location during that cycle. This cycle 
is most useful in multiprocessing systems where certain memory locations are used 
to control access to certain systems resources. (For example, semaphore 
locations.) 

REQUESTER 

A functional module that resides on the same board as a MASTER or INTERRUPT 
HANDLER and requests use of the DTB whenever its MASTER or INTERRUPT 
HANDLER needs it. 

SERIAL CLOCK DRIVER 

A functional module that provides a periodic timing signal that synchronizes 
operation of the VMSbus. (Although the VMEbus specification defines a SERIAL 
CLOCK DRIVER for use with the VMSbus, and although it reserves two backplane 
signal lines for use by that bus, the VMSbus protocol is completely independent of 
the VMEbus). A specification for the timing of the signal generated by the SERIAL 
CLOCK DRIVER is given in appendix C. 

SLAVE 

A functional module that detects DTB cycles initiated by a MASTER and, when 
those cycles specify its participation, transfers data between itself and the 
MASTER. 

SLOT 

A position where a board can be inserted into a VMEbus backplane. If the VMEbus 
system has both a J1 and a J2 backplane (or a combination J1/J2 backplane) each 
slot provides a pair of 96 pin connectors. If the system has only a J1 backplane, 
then each slot provides a single 96 pin connector. 

SUBRACK 

A rigid framework that provides mechanical support for boards inserted into the 
backplane, ensuring that the connectors mate properly and that adjacent boards do 
not contact each other. It also guides the cooling airflow through the system, and 
ensures that inserted boards do not disengage themselves from the backplane due 
to vibration or shock. 

SYSTEM CLOCK DRIVER 

A functional module that provides a 16 Mhz timing signal on the UTILITY BUS. 

SYSTEM CONTROLLER BOARD 

A board which resides in slot 1 of a VMEbus backplane and has a SYSTEM 
CLOCK DRIVER, a DTB ARBITER an JACK DAISY CHAIN DRIVER, and a BUS 
TIMER. Some also have a SERIAL CLOCK DRIVER, a POWER MONITOR, or both. 
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UAT 

A MASTER that sends or receives data in an unaligned fashion, or a SLAVE that 
sends and receives data in an unaligned fashion, 

OR 
a SLAVE that sends and receives data in an unaligned fashion. 

UTILITY BUS 

One of the four buses provided by the VMEbus backplane. This bus includes 
®!Pw?J^,:^* provide periodic timing and coordinate the power-up and power-down 
of VMEbus systems. r k ■ 

WRITE CYCLE 

A DTB cycle used to transfer 1 ,2,3, or 4 bytes from a MASTER to a SLAVE. The 
cycle begins when the MASTER broadcasts an address and address modifier and 
places data on the DTB. Each SLAVE captures this address and address modifier, 
and checks to see if it is to respond to the cycle. If so, it stores the data and then 
acknowledges the transfer. The MASTER then terminates the cycle. 
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INTRODUCTION 

This appendix describes the VI\/IEbus signal lines. The following table identifies the 
VMEbus signals by signal mnemonic, and describes the signal characteristics. 



i 



VMEbus Signal Identification 



SIGNAL 
MNEMONIC 

A01-A15 



A16-A23 



A24-A31 



ACFAIL* 



AM0-AM5 



AS* 



BBSY* 



SIGNAL NAME AND DESCRIPTION 

ADDRESS bus (bits 1-15) - Three-state driven address 
lines that are used to broadcast a short, standard, or 
extended address. 

ADDRESS bus (bits 16-23) - Three-state driven address 
lines that are used in conjunction with A01-A15 to 
broadcast a standard or extended address. 

ADDRESS bus (bits 24-31) - Three-state driven address 
lines that are used in conjunction with A01-A23 to 
broadcast an extended address. 

AC FAILURE - An open-collector driven signal which 
indicates that the AC input to the power supply is no longer 
being provided or that the required AC input voltage levels 
are not being met. 

ADDRESS MODIFIER (bits 0-5) - Three-state driven lines 
that are used to broadcast information such as address 
size, cycle type, and/or MASTER identification. 

ADDRESS STROBE - A three-state driven signal that 
indicates when a valid address has been placed on the 
address bus. 

BUS BUSY - An open-collector driven signal driven low by 
the current MASTER to indicate that it is using the bus. 
When the MASTER releases this line, the resultant rising 
edge causes the ARBITER to sample the bus grant lines 
and grant the bus to the highest priority requester. 
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SIGNAL 
MNEMONIC 

BCLR* 



BERR* 



BG0IN*-BG3IN* 



BG0OUT*-BG3OUT* 

BR0*-BR3* 

D00-D31 
DSO*, DS1* 



DTACK* 



GND 



SIGNAL NAME AND DESCRIPTION 

BUS CLEAR - A totem-pole driven signal, generated by an 
ARBITER to indicate when there is a higher priority request 
for the bus. This signal requests the current MASTER to 
release the DTB . 

BUS ERROR - An open-collector driven signal generated by 
a SLAVE or BUS TIMER. This signal indicates to the 
MASTER that the data transfer was not completed. 

BUS GRANT (0-3) IN - Totem-pole driven signals generated 
by the ARBITER and REQUESTERS. "Bus grant in" and 
"bus grant out" signals form bus grant daisy chains. The 
"bus grant in" signal indicates, to the board receiving it, that 
it may use the DTB. 

BUS GRANT (0-3) OUT - Totem-pole driven signals 
generated by REQUESTERS. The bus grant out signal 
indicates to the next board in the daisy-chain that it may use 
the DTB. 

BUS REQUEST (0-3) - Open-collector driven signals 
generated by REQUESTERS. A low level on one of these 
lines indicates that some MASTER needs to use the DTB. 

DATA BUS - Three-state driven bidirectional data lines 
used to transfer data between MASTERS and SLAVES. 

DATA STROBE ZERO, ONE - Three-state driven signals 
used in conjunction with LWORD* and A01 to indicate how 
many data bytes are being transferred (1 , 2, 3, or 4). During 
a write cycle, the falling edge of the first data strobe 
indicates that valid data is available on the data bus. On a 
read cycle, the rising edge of the first data strobe indicates 
that data has been accepted from the data bus. 

DATA TRANSFER ACKNOWLEDGE - An open-collector 
driven signal generated by a SLAVE. The falling edge of 
this signal indicates that valid data is available on the data 
bus during a read cycle, or that data has been accepted 
from the data bus during a write cycle. The rising edge 
indicates when the SLAVE has released the data bus at the 
end of a READ CYCLE. 

The DC voltage reference for the VMEbus system. 



256 



APPENDIX B 



SIGNAL 
MNEMONIC 

lACK* 



lACKIN* 



lACKOUT* 



IRQ1*-IRQ7* 



LWORD* 

RESERVED 
SERCLK 
SERDAT* 
SYSCLK 

SYSFAIL* 



SIGNAL NAME AND DESCRIPTION 

INTERRUPT ACKNOWLEDGE - An open-collector or three- 
state driven signal used by an INTERRUPT HANDLER 
acknowledging an interrupt request. It is routed, via a 
backplane signal trace, to the lACKIN* pin of slot 1, where it 
is monitored by the lACK DAISY-CHAIN DRIVER. 

INTERRUPT ACKNOWLEDGE IN - A totem-pole driven 
signal. The lACKIN* and lACKOUT* signals form a daisy- 
chain. The lACKIN* signal indicates to the VMEbus board 
receiving it that it is allowed to respond to the INTERRUPT 
ACKNOWLEDGE CYCLE that is in progress. 

INTERRUPT ACKNOWLEDGE OUT - A totem-pole driven 
signal. The lACKIN* and lACKOUT* signals form a daisy- 
chain. The lACKOUT* signal is sent by a board to indicate 
to the next board in the daisy-chain that it is allowed to 
respond to the INTERRUPT ACKNOWLEDGE CYCLE that 
is in progress. 

INTERRUPT REQUEST (1-7) - Open-collector driven 
signals, generated by an INTERRUPTER, which carry 
interrupt requests. When several linds are monitored by a 
single INTERRUPT HANDLER the highest numbered line is 
given the highest priority. 

LONGWORD - A three-state driven signal used in 
conjunction with DSO*, DS1*, and A01 to select which byte 
location(s) within the 4 byte group are accessed during the 
data transfer. 

RESERVED - A signal line reserved for future VMEbus 
enhancements. This line MUST NOT be used. 

SERIAL CLOCK - A totem-pole driven signal which is used 
to synchronize the data transmission on the VMSbus. 

SERIAL DATA - An open-collector driven signal which is 
used for VMSbus data transmission. 

SYSTEM CLOCK - A totem-pole driven signal which 
provides a constant 16-MHz clock signal that is 
independent of any other bus timing. 

SYSTEM FAIL - An open-collector driven signal that 
indicates that a failure has occurred in the system. This 
signal may be generated by any board on the VMEbus. 
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SIGNAL 
MNEMONIC 

SYSRESET* 
WRITE* 

+5V STDBY 

+5V , 

+12V 

-12V 



SIGNAL NAME AND DESCRIPTION 

SYSTEM RESET - An open-collector driven signal which, 
when low, causes the system to be reset. 

WRITE - A three-state driven signal generated by the 
MASTER to indicate whether the data transfer cycle is a 
read or a write. A high level indicates a read operation; a 
low level indicates a write operation. 

+5 Vdc STANDBY - This line supplies +5 Vdc to devices 
requiring battery backup. 

+5 Vdc Power - Used by system logic circuits. 

+12 Vdc Power - Used by system logic circuits. 

-1 2 Vdc Power - Used by system logic circuits. 
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Two signal lines on the VMEbus backplane (SERCLK and SERDAT*) are designated 
for use by the VMSbus and provide a serial communication link between boards. The 
protocol used on the VMSbus is outside the scope of this document. Since system 
controller board designers will want to include circuitry on their boards to drive 
SERCLK, this appendix provides the necessary information. 

SERCLK, like SYSCLK has no fixed timing relationship with any VMEbus signal 
(except SERDAT* which carries data bits that are synchronized to SERCLK). 

The drivers and receivers for SERCLK and SERDAT* are specified in Chapter 7. 

Figure C-1 andTable C-1 show the required timing parameters for the SERCLK signal 
line. A SERCLK waveform with these timing values can be derived from a 32 Mhz 
clock source. The timing values in Table C-1 are for use when the SERCLK and 
SERDAT* lines are not extended beyond the VMEbus backplane. If these signals are 
extended to carry intersystem information, each of the timing values given inTtable C-1 
should be multiplied by a common scaling factor, greater than 1, to allow for the 
increased SERCLK and SERDAT* propagation times. 

RECOMMENDATION 0.1: 

When designing the SERIAL CLOCK DRIVER module, take into account the fact that 
the SERCLK line driver's propagation delays for the rising and falling edges will likely 
be different. This difference is emphasized when the SERCLK line is heavily loaded: 
When calculating the driver's propagation delays, use the delays specified on the 
manufacturer's data sheet for a 300 pf capacitive load. If the only propagation delays 
given are for a 30 pf load, add 10 nSec to each of the propagation delays. 

SUGGESTION C.1: 

Design the SERIAL CLOCK DRIVER so that it can be jumpered to work from various 
stages of a binary counter that is driven by a 32 Mhz clock source. This allows the 
selection of 32 Mhz , 16 Mhz , 8 Mhz, etc., as the base frequency for the SERIAL 
CLOCK DRIVER and makes it easy to select a frequency appropriate for the length of 
the SERCLK and SEF^DAT* lines. 

OBSERVATION C.1: 

If a 32 Mhz clock source is used to generate the SERCLK waveform, it can also be 
used to generate the VMEbus's 1 6 Mhz SYSCLK signal. 

SUGGESTION C.2: 

To allow multiple boards that include SERIAL CLOCK DRIVER to be installed in the 
same backplane, design them with a jumper that disconnects the SERIAL CLOCK 
DRIVER from the SERCLK line. 
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- ONE SERCLK CYCLE - 



32 MHz 
CLOCK SOURCE 



a 



I -' — h'i — ' — HH 



SERCLK 




.8-0 tl 0.8 



Note: 



See Table C-1 on the following page for timing values. 



Figure C-1. SERCLK Timing Diagram 
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Table C-1 . SERCLK Timing Values 



PARAMETER 
NUMBER 


MIN 


MAX 


1 


167 




2 




194 


3 




51 


4 


25 




5 


74 




6 




100 


7 




51 


8 


25 




9 


340 


347 



B 



Note: 



All timing values are in nanoseconds. 
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